›_ Codex Issues
Codex Issues / #35824

Show local image previews in the TUI

Open 💬 3 comments Opened Jul 28, 2026 by Kpyruy
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

Codex CLI (TUI), tested in Kitty

What feature would you like to see?

When Codex references a local image in its final response, it would be useful to show a small preview directly below the path.

Right now, every referenced image has to be opened separately. This becomes inconvenient when working on UI, screenshots, generated images, or other visual tasks.

The original path should remain visible and clickable. The preview should preserve the image's aspect ratio and remain available after resizing the terminal, scrolling through the transcript, or reopening the session with codex resume.

Only images explicitly referenced in the final response should be shown. Images that Codex opened internally while working should not appear in the transcript.

On terminals without the required image support, or when a file is missing or cannot be decoded, Codex should simply leave the path as normal text.

Additional information

I built a proof of concept for this behavior:

https://github.com/Kpyruy/codex/commit/aaea18d724554c8ec108ba9c3a26a40a7fb6e8f8

It uses the Kitty graphics protocol and supports PNG, JPG/JPEG, WebP, and GIF files. Previews are reconstructed from the saved final response and the session working directory, so they also work after codex resume without storing image data in the conversation history.

The targeted image, streaming, and resume tests pass locally, as does the full codex-tui test suite.

I am opening an issue first as requested in the contribution guidelines. If this approach fits the project's direction, I would be happy to prepare a pull request if invited.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #35755

Powered by Codex Action

ALavault · 12 days ago

Additional real-world reproduction on Linux/Kitty:

  • Codex CLI: 0.147.0
  • OS: Linux 7.0.0-29-generic x86_64
  • Terminal: Kitty (TERM=xterm-kitty, COLORTERM=truecolor, KITTY_WINDOW_ID and KITTY_PID present)
  • No tmux/zellij variables in the Codex environment

Observed behavior:

  1. Ask Codex to display a local PNG.
  2. The built-in image-viewing tool succeeds, but the user-visible TUI only shows:

``text
Viewed Image
└ path/to/image.png
``
No pixels are rendered.

  1. Asking Codex to run kitten icat path/to/image.png from its command executor fails with:

``text
Failed to open controlling terminal with error: open /dev/tty: no such device or address
``
This appears to happen because the captured subprocess has no controlling TTY, even though Codex itself is running interactively in Kitty.

  1. chafa --format symbols --colors 256 generates ANSI output, but the Codex tool-output presentation escapes/sanitizes the control sequences instead of rendering them. --colors none is usable only as a low-fidelity Unicode fallback.

Expected behavior:

  • When view_image succeeds in a terminal advertising Kitty graphics support, Codex TUI should render a bounded inline preview.
  • Image bytes / terminal escape sequences should be emitted by the TUI itself, not by the sandboxed command subprocess.
  • Preserve the path and provide an open/zoom action.
  • Gracefully fall back to a path or monochrome preview when the protocol is unavailable.
  • Keep terminal graphics payloads out of copied text and persisted conversation history.

This is a concrete instance of the feature requested here and also explains why invoking kitten icat through the agent's command runner is not an adequate workaround.

EricBlanquer · 7 days ago

I have a simpler related use case: in the Codex CLI TUI, when an attached image is shown as [Image #1], I would like that label to be actionable so I can reopen or preview the image later from the transcript.

I do not need the original filesystem path to be exposed for this use case. The main need is to make the existing attachment reference usable as a way to view the image again.

Environment:

  • codex-cli 0.149.0
  • Linux
  • Cinnamon
  • Terminator