[BUG] No reliable way to display inline images in the terminal from within Claude Code

Resolved 💬 3 comments Opened Mar 20, 2026 by eendeego Closed Mar 23, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

No reliable way to display inline images in the terminal from within Claude Code

Claude Code's TUI prevents tools and skills from displaying inline images (e.g., charts, diagrams) directly in the terminal. This limits use cases like rendering data visualizations, previewing generated images, or displaying charts from CLI tools that support terminal inline image protocols (iTerm2, Kitty, Sixel).

Problem

There are three approaches to display images from within Claude Code, and none works well:

  1. Read tool on image files: Claude (the model) can "see" the image in its context, but the user's terminal shows nothing — the result is collapsed behind a "ctrl+o to expand" toggle, and even when expanded, the image is not rendered visually in the terminal.
  1. Writing iTerm2 escape sequences to the PTY (/dev/pts/N): The image briefly appears but is immediately overwritten by Claude Code's TUI on its next repaint cycle. Single writes are invisible; even with a 3-second delay, the image appears and disappears within ~1 second.
  1. ANSI scroll regions / alternate screen buffer: Attempting to use \033[N;Mr (scroll regions) or \033[?1049l/\033[?1049h (alt screen) to protect a terminal region from repaints corrupts the terminal state permanently, requiring the user to close and reopen their terminal.

Current workaround

The only way to keep an image visible in the terminal is a continuous re-render loop that writes the iTerm2 image escape sequence to the PTY every ~1 second from a background process:

(while true; do
  printf '\033]1337;File=inline=1;size=%d;...:%s\a\n' "$SIZE" "$BASE64" > /dev/pts/N
  sleep 1
done) &

This works but is wasteful (repeatedly encoding and writing ~30KB+ of base64 data) and produces visible flicker.

Environment

  • Claude Code in VS Code integrated terminal (Remote SSH to Linux devserver)
  • VS Code with terminal.integrated.enableImages enabled
  • Terminal supports iTerm2 inline image protocol (confirmed: images DO render when written to the PTY)

Proposed Solution

  1. Image-aware Read tool output: When the Read tool reads an image file, render it inline in the terminal (using iTerm2/Kitty/Sixel protocol) instead of only making it available to the model's context.
  1. Protected output regions: Allow Bash tool output containing iTerm2/Kitty image escape sequences to pass through to the terminal without being captured/stripped, perhaps via a flag or by detecting image protocol sequences.
  1. Stable render sections: Introduce a concept of "committed" output that the TUI won't repaint over — content above a certain point in the conversation stays rendered and isn't cleared on the next TUI update cycle.
  1. Image display tool: A dedicated tool (or Bash tool option) that writes content directly to the terminal device, bypassing Claude's stdout capture, specifically for inline image display.

Alternative Solutions

Read description above

Priority

Critical - Blocking my work

Feature Category

Interactive mode (TUI)

Use Case Example

I'm working on Data Visualization and want to render charts in the terminal. Later on, I want to render any SVG image (e.g an Excalidraw diagram).

This tweet points at other graphical content that may be rendered using the same approach: https://x.com/thingskatedid/status/1316074032379248640

Additional Context

See content above.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗