Show image artifacts inline in the Codex TUI
TL;DR
<img width="1148" height="826" alt="Image" src="https://github.com/user-attachments/assets/c6911dcb-f950-4a0c-b859-e3315031683f" />
Summary
I would like Codex TUI to show terminal-native previews for image artifacts, especially images opened through view_image and images produced by image_gen.
The goal is to make image-producing workflows reviewable inside the terminal without requiring the user to manually open the generated file in a separate viewer.
Motivation
This comes up in two common workflows:
image_gencreates an image and Codex saves it locally. The current text history can show the path, but the user still needs to open that file separately to inspect the result.- Codex drives a browser or visual regression test, captures screenshots, and then uses
view_imageto inspect them. The screenshot is often the most important output for the user to review, so it should be visible in the TUI history where the rest of the task context lives.
Codex already has terminal image plumbing for pets, so this seems like a good fit for reusing the existing protocol detection and rendering path rather than introducing a separate terminal graphics stack.
Proposed behavior
When an image artifact is available in TUI history:
- keep the existing text history entry, including the file path
- if the terminal supports image output, render a small preview below the history entry
- use the existing pets terminal image support where possible
- prefer Kitty graphics when available
- fall back to Sixel when Kitty is unavailable but Sixel is detected
- if neither protocol is available, keep the current text-only behavior
The terminal graphics bytes should remain terminal-only output. They should not be included in model-visible context, raw transcript text, or replayable text surfaces.
Related issues
- #6123 requested terminal-rendered image previews, but it was closed as stale / no upvotes. This request is narrower and tied to current
view_image/image_genartifact workflows. - #27335 is related to Sixel detection for pets in VS Code, which would also affect any feature that reuses the pets image protocol detection path.
- #28887 is related to
image_genexposing usable saved paths. This request assumes an artifact path is available and focuses on showing that artifact in the TUI.
Local prototype
I have a local prototype branch here:
- Branch: https://github.com/mizchi/codex/tree/terminal-image-previews
- Compare: https://github.com/openai/codex/compare/main...mizchi:terminal-image-previews
High-level shape of the prototype:
- adds a
terminal_imagemodule for terminal-only image preview payloads - reuses the existing pets Kitty/Sixel support
- adds terminal image metadata to rich history lines without adding escape payloads to text surfaces
- reserves scrollback rows for previews in
insert_history - sends Kitty previews with
C=1so the terminal does not also advance the cursor; the TUI controls row reservation itself - keeps raw/transcript display surfaces text-only
Open questions / known limitations
- Preview sizing is heuristic. The right size and aspect ratio can depend on terminal dimensions, surrounding context, image content, and user preference. This likely needs tuning or a future config surface.
- Terminal support varies. Some environments support Kitty graphics, some support Sixel, and some support neither. The feature should degrade cleanly to text-only history.
- Existing pets detection intentionally disables terminal images in tmux/zellij to avoid scrollback/pane issues. Reusing that policy is conservative, but it may be worth revisiting if broader terminal image support is desired.
Validation from the prototype
LIBRARY_PATH=/Users/mz/brew/opt/bzip2/lib just test -p codex-tuiLIBRARY_PATH=/Users/mz/brew/opt/bzip2/lib just test -p codex-tui image_history_cell_text_surfaces_do_not_include_terminal_payloadsLIBRARY_PATH=/Users/mz/brew/opt/bzip2/lib just fix -p codex-tuijust fmt- manually checked
view_imagepreview rendering in Ghostty
Filing note
I originally prepared this as a PR, but external pull requests currently appear to be restricted for this repository. Filing this as a feature request with the fork branch attached for reference.