[Bug]: Completed hosted image results from a routed Responses provider are not displayed in Codex App

[chiperman]

Client or integration

Codex App

Area

Proxy and routing

Summary

With Codex App connected to OpenCodex and using a routed OpenAI-compatible Responses provider, an image request completed successfully upstream, but the generated image was not displayed in the conversation. The session contained a completed image_generation_call with valid image data, without a corresponding usable image file or displayable assistant image message.

Expected: when this supported hosted-image path returns a valid result, the local Codex client should receive a usable image output, including a displayed image or accessible artifact.

This report concerns hosted image results returned inside /v1/responses, not a failed standalone /v1/images/generations request. The original Responses request returned HTTP 200. The evidence establishes a persistence/display compatibility gap in this configuration; it does not establish that OpenCodex alone is the root cause.

Reproduction

1. Use OpenCodex 2.64.0 with Codex App connected to its local proxy. The separate Desktop application build was not recorded.
2. Configure a keyed openai-responses provider and select its routed model. Provider and model identifiers below are placeholders.
3. Ask the built-in image tool to generate a simple landscape.
4. For the failing attempt, the provider returned a hosted image_generation_call in the Responses output, with status: completed and a non-empty result.
5. Observe that the conversation does not show the generated image. Inspecting the session and decoding the result locally confirms that complete image data was received.

The live failure was captured once and reproduced by replaying that captured response through the local delivery code. Tool selection can choose a different path, so this is not a claim that every image request fails. A client-side image tool call using the standalone Images route and native generated-image output worked in the same environment.

Version

2.64.0

Operating system

macOS (exact version omitted for privacy)

Provider and model

An OpenAI-compatible Responses provider; adapter: openai-responses; authMode: key. Provider and model names are withheld for privacy. example-provider and example-model below are placeholders.

Logs or error output

Sanitized diagnostic summary; payload, identifiers and exact sizes omitted.
Method/path: POST /v1/responses
HTTP status: 200
Output item type: image_generation_call
Output item status: completed
Result: non-empty base64
Decoded image: valid PNG
Observed client behavior: no displayed image or usable local image artifact for this result

Screenshots and supporting files

No raw session logs or full image payloads are attached.

A local compatibility prototype in the Responses delivery layer validates and saves hosted image results, then emits an assistant message containing a local image reference for loopback Codex clients. Raw upstream replay items are preserved; generic/remote clients are left unchanged. The prototype passed 11 targeted tests covering SSE/JSON delivery, terminal snapshots, invalid image data, normal tool/text output, and client scoping. After restarting the local service, a live request produced a valid PNG and a displayable assistant image message. This is local validation only, not a claim of full repository CI coverage or an accepted upstream design.

Related reports and changes:

• image_gen returns image data in session records but no image is shown, saved, or exposed as a path openai/codex#32153 — closely related missing image/path symptom, but its reported item status was generating; this report has completed.
• [codex] Persist built-in image results reported as generating openai/codex#28656 — addresses persistence when status remains generating; that condition differs from this capture.
• [Bug]: Codex App feature surfaces (Astra trial prompt, built-in image generation) stop working through the proxy #4213 and fix(images): use managed Pool with proxy admission bearer, scope first #6097 — related image failures through the proxy, but the managed-account/authentication 400 differs from the successful Responses result here.
• fix(openai-responses): round-trip image-gen namespace #588 — image namespace compatibility explicitly retains hosted-only requests.

Would maintainers prefer a narrowly scoped local-client display adapter in OpenCodex, or should this hosted-result handling be addressed exclusively in the Codex client? A follow-up PR can include the regression fixture and proposed compatibility boundary.

Redacted configuration

Illustrative shape only; provider and model identifiers are placeholders, and endpoints and credentials are omitted.

{
  "providers": {
    "example-provider": {
      "adapter": "openai-responses",
      "authMode": "key",
      "models": ["example-model"]
    }
  }
}

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[Ingwannu]

Linking #6233 as the active hosted-image-result fix proposal. This is the successful /v1/responses image result path, not the standalone image endpoint authentication failure in #4213; those should not be closed as duplicates. #6233 remains draft and records a retention boundary plus pending fresh Desktop rendering/reopen acceptance. Adapter/generation success alone does not prove that Codex App displays or later reopens the image. Keeping this issue open until the relevant client-visible result is verified and the fix lands.

[github-actions]

_{Automated translation bookkeeping — detected language: English.}