### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement Claude Code displays images as a text placeholder (e.g. `[Image]`), even in terminals that support inline graphics (kitty, WezTerm, Ghostty, iTerm2, foot). Escape sequences emitted by tools run through the Bash tool ar

[FEATURE] Support terminal graphics protocols for inline image display

Status Open

Maintainer reply None cached

Activity 6 comments · opened Jul 21, 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

Claude Code displays images as a text placeholder (e.g. [Image]), even in terminals
that support inline graphics (kitty, WezTerm, Ghostty, iTerm2, foot). Escape sequences
emitted by tools run through the Bash tool are captured and stripped, so terminal
graphics tools cannot render either. There is currently no way to view an image
Claude reads or generates without leaving the terminal.

Proposed Solution

Render images inline when the terminal supports a graphics protocol (kitty graphics
protocol, iTerm2 inline images, sixel), with fallback to the current placeholder.

For example, when Claude reads a PNG or a screenshot, the TUI could display it the
same way kitten icat does, instead of [Image]. Alternatively (or additionally),
allow escape-sequence passthrough for whitelisted commands like kitten icat,
imgcat, or chafa, so existing tools can handle the rendering.

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

Working on a data pipeline, I ask Claude Code to plot a metric:

"Plot the request latency from logs.csv and show me the result"

Claude writes a matplotlib script, runs it, and saves latency.png. Today I have to
switch to another terminal or an image viewer to see it. With graphics protocol
support, the plot would appear directly in the conversation, the same way
kitten icat latency.png renders it, and I could iterate ("zoom into the spike
around 14:00") without leaving Claude Code.

Same applies to reviewing screenshots from UI tests, diffing generated assets, or
inspecting images Claude reads with the Read tool.

Additional Context

Yazi and ranger

render image previews via kitty graphics / iTerm2 / sixel with protocol auto-detection.

timg, viu and

chafa detect the best available protocol and fall
back to unicode half-blocks, which would work in any terminal as a lowest tier.

kitten icat documents the kitty

graphics protocol side.

View original on GitHub ↗

3 Comments

nikicat · 2 months ago

Strong +1, with a concrete cross-surface use case: our plugin (claude-ppq) tops up an API balance over Bitcoin Lightning and needs the user to scan a QR code mid-conversation.

Desktop app: Claude saves the invoice QR as a PNG and Reads it — renders inline, the user scans it off the screen. Works great.
Terminal CLI: the same flow displays nothing (not even a placeholder for the Read result — tested in rio on 2.1.210), so we maintain a parallel path: a half-block Unicode QR in the Bash output — which in turn breaks on GUI surfaces that render line gaps.

Graphics-protocol rendering with the placeholder fallback would collapse those two paths into one and give the CLI parity with desktop for any "the image is the deliverable" flow: QR codes, screenshot-verification loops, generated images.

EugeneSusla · 2 months ago

Until there's native support, a userland workaround that needs no changes to Claude Code itself: ccimg — a small script Claude runs as an ordinary Bash command (ccimg <image>), rendering the image inline in the transcript via the kitty graphics protocol's Unicode placeholders (works in ghostty and kitty).

The placeholder cells go to stdout as regular tool output, so the image scrolls with the conversation; the pixel data travels out-of-band straight to the session's pty. Caveats: Linux only, needs a Unicode-placeholder terminal (no sixel/iTerm2 backend yet), and it works best with claude --verbose — non-verbose sessions collapse tall tool results, leaving the image visible only via ctrl+o transcript view.

yrbane · 1 month ago

+1, adding a concrete data point from a Linux desktop setup.

Environment: Debian 13 (trixie), gnome-terminal 3.56.2 / VTE 0.80.1, TERM=xterm-256color, Claude Code CLI.

What I tried:

Asked Claude to display an image after installing chafa. Bash tool output is not forwarded to the terminal, so the rendering never reaches me. The only thing that got through was a colorless, ASCII-only chafa --colors none --symbols ascii render pasted into a code block.
Claude then tried emitting raw ANSI SGR sequences (ESC[31m...ESC[0m) in its reply as a test. They are stripped by the markdown renderer: I see plain text, no color.

So today there is no path at all for the assistant to show a picture, or even colored text, in the CLI. The workaround is to run ! chafa <file> myself, which works but defeats the purpose.

What would help, in order of value:

Pass through Kitty graphics / Sixel / iTerm2 OSC 1337 when the terminal advertises support (this issue).
As a cheaper fallback for terminals without graphics protocols (like VTE-based ones), allow ANSI color sequences inside fenced code blocks to survive rendering, so tools like chafa and timg become usable.
SendUserFile already exists for the mobile/web clients; a CLI-side equivalent that opens the image in the local viewer (xdg-open) would be a reasonable interim solution.

Showing cached comments. Read the full discussion on GitHub ↗