›_ Codex Issues
Codex Issues / #35371

Codex Remote on iOS shows tool images during execution but drops them from the completed turn

Open 💬 4 comments Opened Jul 25, 2026 by lyrabird

Environment

  • Codex desktop app: 26.721.4979.0
  • Host OS: Windows 11 Pro, version 10.0.26200, 64-bit
  • Remote client: ChatGPT app on iPhone, Codex Remote Control
  • Subscription: ChatGPT Pro
  • Reproduced repeatedly on July 26, 2026 (Asia/Shanghai)

Issue

When Codex running on the Windows host produces or views an image, the image is successfully relayed to the ChatGPT iOS Remote Control client and is briefly visible while the turn is running. As soon as the turn completes and the mobile UI switches to the completed/final response view, the image disappears. Reopening or refreshing the completed task still shows only the final text.

This is not a basic transport failure: the same iPhone renders the actual image bytes during the live execution stream. The failure occurs at completion/replay, when the image-bearing tool item is no longer rendered or bound to the final response.

Steps to reproduce

  1. Connect the ChatGPT iOS app to a Windows Codex Desktop host using Codex Remote Control.
  2. Start a task from the phone.
  3. Have Codex invoke the local image viewer or return an image-generation result.
  4. Observe that the image appears correctly on the phone while the turn is running.
  5. Wait for the turn to complete.
  6. Observe that the completed task view contains the final text but no image.
  7. Reopen or refresh the task; the image remains absent.

The behavior was reproduced with:

  • a local image returned through the image-view/tool-output path;
  • a generated-image result;
  • an image referenced from the final response;
  • a publicly reachable HTTPS image reference.

Expected behavior

Any image successfully displayed during a turn should remain visible in the completed turn and after reopening the task. It should be retained as a persistent image/tool item or promoted to an attachment associated with the final response.

Actual behavior

The image is visible only during the live execution stream. After turn/completed, the mobile final view replays only the assistant text and drops the image.

Sanitized rollout evidence

Inspection of the local rollout JSONL for one reproduction showed:

| Record | Payload | Image present | Size |
|---|---|---:|---:|
| Image tool result | custom_tool_call_output containing input_image / image_url | Yes | approximately 1,306,900 characters |
| Final assistant message | message with content type output_text only | No | 468 characters |

The image bytes therefore reached and were persisted in the turn record, but were not associated with the final assistant message.

This also matches the current App Server item model documented at <https://learn.chatgpt.com/docs/app-server#items>: agentMessage contains text, while imageView and image-bearing dynamic tool results are separate items.

Impact

This blocks visual review from Codex Remote. A user can briefly see a generated screenshot, design candidate, chart, or other image while execution is active, but cannot inspect it after completion or return to it later. External storage links are not equivalent because they require leaving the task and do not provide the expected inline final result.

Suggested fix area

One of the following would address the issue:

  1. Keep rendering completed imageView items and image-bearing dynamicToolCall.contentItems after turn/completed, including when reopening task history.
  2. Promote image tool results to a persistent attachment associated with the final answer.
  3. Add first-class image/attachment content to the final agentMessage representation.
  4. Ensure the mobile Remote client fetches and renders the full persisted item history rather than only the final text summary.

The reporter can provide redacted screenshots and additional rollout metadata if needed.

View original on GitHub ↗

4 Comments

vanek-nutic · 29 days ago

Independent reproduction from a macOS Codex host confirms the same failure across all available image-result paths.

Environment:

  • Codex macOS app: 26.721.41059 (build 5848)
  • Bundle ID: com.openai.codex
  • Bundled CLI: codex-cli 0.146.0-alpha.3.1
  • Mobile client: Codex Remote on a phone; exact mobile OS/app version was not captured
  • Reproduced: 2026-07-30

Observed sequence:

  1. An image appears correctly during the live turn.
  2. Leave and reopen the same thread.
  3. The image disappears while the surrounding turn text remains.

Independent controls all reproduced the failure:

  • view_image with a different local PNG and no MCP call;
  • JPEG bytes embedded in an image-bearing tool result;
  • the built-in first-class imageGeneration result using a neutral four-color test card.

For the generated-image control, stored thread readback still recorded the item as type: imageGeneration, status: completed, and the generated PNG remained present and valid on the Mac host. The mobile image nevertheless disappeared after reopening the thread.

This rules out the original image, duplicate-image reuse, MCP activity, source-file deletion, and image-generation failure. It supports the issue's suspected completion/replay or mobile thread-reconstruction boundary. I can provide the redacted thread ID and additional local metadata privately if useful.

JakobSung · 24 days ago

Additional reproduction from a Codex mobile-app user (2026-08-04; mobile platform and app version were not captured):

  • I asked Codex to create six logo concept images.
  • Image generation completed and the assistant returned six image result blocks.
  • In the mobile app, the surrounding assistant text was visible, but none of the generated image previews rendered.
  • Re-displaying the same generated PNGs did not make them visible in the mobile app.

Expected: generated image result blocks should render inline in the mobile app, or provide a clear artifact/download fallback.

Actual: the image content is absent while the surrounding text remains visible.

This appears consistent with the image-loss/replay problem described in this issue, although the exact mobile OS and app version were not captured.

jhodges10 · 19 days ago

Additional independent reproduction on 2026-08-08:

  • Host: Codex Desktop on Windows
  • Remote client: ChatGPT/Codex Remote on an iPad
  • Content: a 2x PNG screenshot produced by Native SDK automation from a local retained-canvas timeline

Observed three times in the same remote thread:

  1. Returning the local PNG through the normal inline image/tool-output path made the screenshot appear briefly while the turn was active.
  2. As soon as the assistant finalized the turn, the screenshot disappeared and only the text remained.
  3. Re-sending it through the image-generation-style attachment/result wrapper behaved the same way: visible briefly, then removed at completion.
  4. Repeating the original inline path reproduced the disappearance again.

The source PNG remained present and readable on the Windows host throughout, and the host-side image viewer rendered it successfully each time. This further isolates the failure to iPad Remote completion/replay rather than image creation, file lifetime, or local decoding.

lukehami55 · 18 days ago

Additional reproduction confirmation (August 9, 2026):

  • Host: Codex Desktop 26.803.5235.0 on Windows 11 Pro 10.0.26200, 64-bit
  • Client: ChatGPT mobile app on iPhone using Codex Remote (mobile app version not captured)
  • Content: ten local PNG concept images returned through the image-view/tool-output path

Observed behavior:

  1. While the turn remained active, all ten images rendered correctly on the iPhone and could be opened/saved.
  2. The turn was intentionally kept active; the images continued to remain visible.
  3. Immediately after the assistant emitted the final response and the turn completed, the image previews disappeared.
  4. Reopening the completed task did not restore them.
  5. Final-response links to the Windows C:\... paths were visible but, as expected, could not be resolved by the phone.

This strongly reproduces the completion/replay boundary described in this issue: image transport to Remote succeeds, but the completed-turn representation drops the image-bearing tool items. Preserving those items after completion—or offering a way to promote selected tool images to persistent final-response attachments—would solve the workflow.

A redacted mobile screenshot demonstrating the gray/missing image state is available if maintainers need it. No patient or repository data is included in this report.