Repository navigation
Codex Remote on iOS shows tool images during execution but drops them from the completed turn #35371
Description
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
- Connect the ChatGPT iOS app to a Windows Codex Desktop host using Codex Remote Control.
- Start a task from the phone.
- Have Codex invoke the local image viewer or return an image-generation result.
- Observe that the image appears correctly on the phone while the turn is running.
- Wait for the turn to complete.
- Observe that the completed task view contains the final text but no image.
- 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:
- Keep rendering completed
imageViewitems and image-bearingdynamicToolCall.contentItemsafterturn/completed, including when reopening task history. - Promote image tool results to a persistent attachment associated with the final answer.
- Add first-class image/attachment content to the final
agentMessagerepresentation. - 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.
Activity
vanek-nutic commentedon Jul 30, 2026
Independent reproduction from a macOS Codex host confirms the same failure across all available image-result paths.
Environment:
26.721.41059(build5848)com.openai.codexcodex-cli 0.146.0-alpha.3.1Observed sequence:
Independent controls all reproduced the failure:
view_imagewith a different local PNG and no MCP call;imageGenerationresult 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 commentedon Aug 4, 2026
Additional reproduction from a Codex mobile-app user (2026-08-04; mobile platform and app version were not captured):
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 commentedon Aug 8, 2026
Additional independent reproduction on 2026-08-08:
Observed three times in the same remote thread:
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 commentedon Aug 10, 2026
Additional reproduction confirmation (August 9, 2026):
26.803.5235.0on Windows 11 Pro10.0.26200, 64-bitObserved behavior:
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.
avesus commentedon Oct 3, 2026
Additional user report, received October 3, 2026: this behavior persists in ChatGPT on iPhone when using Codex connected to a Windows PC.
Observed sequence:
The user reports that the final PNG consistently fails this way and that the problem has continued across app updates.
Expected behavior: the final PNG should display and open on the iPhone after task completion. Reports already displayed during execution should remain accessible.
This report adds a specific detail to the existing issue: some earlier reports remain accessible inside expanded activity, while the final PNG is present as an unviewable gray block. The user has not confirmed whether that exact final PNG opens in the Windows app. Exact app and operating-system versions, screenshots, and diagnostic logs were not collected for this report.
These are user-reported observations; the root cause has not been verified.
uk-kim commentedon Oct 17, 2026
Additional reproduction report — 2026-10-17 (Asia/Seoul).
The affected user explicitly asked the assistant to report this. The observations below distinguish the user's mobile observations from checks performed on the host.
Environment
Observed sequence
Important distinction
This is not "images never work on the phone": live tool-image display succeeds, while completed-turn display fails. Please investigate completion/history rendering and persistence of image-bearing items in the mobile Remote client.
Host checks
Expected behavior
An image visible during execution should remain available after completion and when revisiting the answer. If inline persistence is unsupported, provide a reliable open/download attachment instead of an indefinite spinner. Attachment-specific final-answer markup was also visible as literal text in the user's screenshot.
No project contents, local paths, screenshots containing unrelated conversation content, or private logs are included in this public report. Root cause is not confirmed.