codex resume dumps raw base64 of inline images to the terminal (IntelliJ IDEA terminal, 0.143.0)

Open 💬 4 comments Opened Jul 8, 2026 by angoxxx

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.143.0

What subscription do you have?

Which model were you using?

gpt-5.5

What platform is your computer?

_No response_

What terminal emulator and version are you using (if applicable)?

IntelliJ IDEA terminal

Codex doctor report

What issue are you seeing?

What happened?

After upgrading to codex-cli 0.143.0, running codex resume on a session whose history contains an inline image (a pasted screenshot / input_image) causes Codex to spam the terminal with the raw base64 of the image instead of rendering (or skipping) it. Output looks like repeated inline-image / Kitty graphics protocol leaking as plain text, e.g.:

Ga=T,t=d,f=100,c=9,r=5,q=2,i=49374,m=1;iVBORw0KGgoAAAANSUhEUgAA... (thousands of base64 chars) ...

This happens in terminals without terminal-graphics support — here, the IntelliJ IDEA built-in terminal. The same session resumed fine on the previous version, and resuming in iTerm2/kitty/WezTerm doesn't spam.

Environment: codex-cli 0.143.0 · macOS (Darwin 25.5.0), Apple Silicon · IntelliJ IDEA built-in terminal

Notes: Likely introduced by 0.143.0's resume history replay (#28426 "Share resumed rollout history"). Same area as #31222 (slow resume with multiple terminal images) and #31040 (compaction re-embeds screenshots). Suggested fix: gate inline-image emission on detected terminal graphics capability + text fallback.

What steps can reproduce the bug?

Steps to reproduce

On 0.143.0, have a session whose history contains an inline image.
Exit the session.
In a terminal without graphics support (IDEA built-in terminal), run codex resume and pick that session.
Raw base64 floods the terminal on history replay (needs reset to recover).

What is the expected behavior?

Expected: render only when the terminal advertises graphics support, else fall back to a [image] text placeholder — never emit raw base64.

Actual: full image payload dumped as raw base64, garbling the terminal.

Additional information

_No response_

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

#31222

Powered by Codex Action

mayank6091 · 1 month ago

@angoxxx This also highlights the value of separating execution artifacts from user-facing output. Once binary payloads and execution metadata share the same output channel, debugging becomes unnecessarily difficult.

angoxxx · 1 month ago

Personal implementation notes for a later local fix attempt: 问题是 codex resume 在 IntelliJ IDEA 内置终端等不支持 terminal graphics 的环境里，误输出 Kitty/WezTerm inline image payload 的 base64。修复方向应是通用能力门控，而不是 JetBrains 专用特判：不要仅凭可能从父 shell 继承来的 KITTY_WINDOW_ID、WEZTERM_VERSION 或 WEZTERM_EXECUTABLE 就启用 Kitty image protocol；只有当前终端身份、TERM 或 TERM_PROGRAM 明确表明支持 Kitty/Ghostty/WezTerm 图形协议时才启用。若存在明确的冲突终端身份，例如 TERMINAL_EMULATOR=JetBrains-JediTerm，且它不是 Kitty/Ghostty/WezTerm，则应阻止继承来的 graphics env 单独开启图片输出。同时收紧 iTerm2 判断，避免用 contains("iterm") 把 JediTerm 误判成 iTerm2。请在 codex-rs/tui/src/pets/image_protocol.rs 附近实现，保持改动小而通用，并加回归测试：冲突终端身份 + stray Kitty/WezTerm env 应返回 unsupported；真实 Kitty/WezTerm 仍应 supported；JediTerm 不应触发 iTerm2 fallback。

saime428 · 1 month ago

One extra clue narrows this down: i=49374 is decimal 0xC0DE, the fixed image ID passed by render_ambient_pet_image(). I also checked the call sites; resumed input images do not use that encoder. The raw Kitty payload is coming from the configured terminal pet, with resume only triggering its redraw.