[Feature]: Show Codex Image View results as inline previews on mobile

[bakinrob]

Problem or use case

I use T3 Code on my iPhone to direct Codex while making videos. When Codex successfully uses the view_image / “Image view” tool to inspect a frame or storyboard image, the mobile UI shows only the absolute local path from the host computer, such as /Users/.../fragment-0001.jpg.

Codex can inspect the image, but I cannot see it on my phone. That makes it difficult to confirm whether the video is going in the right direction without returning to the host computer. The regular Codex interface displays the inspected images inline.

Proposed solution

For completed image-view tool calls on mobile:

• Show an inline thumbnail of the inspected image.
• Let the user tap it for a larger/full-screen preview.
• Show the filename as secondary information.
• When several images are inspected, optionally provide simple gallery/swipe navigation.
• Fall back to the current path-only display when a preview is unavailable.

Security considerations

The mobile client should not receive unrestricted filesystem access. The server could expose only the specific image associated with the authorized tool call through an authenticated, scoped resource endpoint.

Acceptance criteria

• A successful Codex Image View call displays its image inline in the mobile conversation.
• Tapping the thumbnail opens a larger preview.
• It works when the T3 Code client is on a phone and the file is on the connected host computer.
• Missing or unsupported files fail gracefully.
• The preview mechanism cannot be used to browse arbitrary local paths.

Environment

Observed in the T3 Code mobile interface on iPhone while controlling Codex on a Mac.

I have screenshots showing the current path-only behavior and can add them if useful.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Issue #7555 confirms that the same path-only Image View result also affects web and desktop.

The report reproduces on the macOS desktop nightly with the Codex provider. A successful agent-side Image View tool call appears in the tool-call list, but expanding it shows only the absolute host path in a code block. Images uploaded by the user already preview correctly, so the missing case is specifically a file that the agent inspected from disk. The user must leave T3 Code and open the path in Finder or Preview to verify what the agent saw.

Please treat web and desktop as part of this discussion's client scope, alongside mobile. The same authenticated, tool-call-scoped resource should support inline thumbnails and larger previews without granting general filesystem browsing. The current path display remains the fallback for missing or unsupported files. I am preserving the cross-client reproduction here before the feature issue closes; its environment and full steps remain in the source report.

[KyuubiYoru]

Another platform, and one detail that widens this past Codex.

I hit this today on Android while an agent worked on my Linux desktop. The task was procedural planet shaders in Godot. That work is a loop: render a frame, look at it, change a value, render again. The agent read five 1600x900 PNG captures off the host with its file-read tool and described them back to me in text. One of those frames is how a real shader bug got caught, so the screenshots were doing work in the session. I just could not see any of them on my phone.

Two additions to what is already here.

Android behaves the same way. This discussion covers iPhone and #7555 covers macOS desktop and web, so the gap is on every client rather than one of them.

It is not specific to Codex. My session runs the Claude Agent provider and the read came from that SDK's file-read tool, not Codex view_image. A fix keyed to one provider's tool name would leave the rest behind.

The security section is doing more work than it looks like it is. I tried the obvious workaround of publishing the screenshots and pasting a markdown image URL. My Git host only serves private repos to authenticated requests, so /raw/ and /media/ both returned 404 to an unauthenticated fetch and nothing rendered. Anyone whose files are not already public cannot route around this themselves, which is the argument for the scoped authenticated endpoint you describe.

I got there in the end by committing the screenshots to the private repo through Git LFS, pushing, and opening each link in a browser already signed in to that host. Two minutes and a permanent commit to look at five images the model had already seen. On a workflow where a human judges what the agent renders, that cost repeats every iteration.

A static thumbnail would be enough for me. The gallery and swipe navigation in the original proposal are nice, but I would be unblocked without them.