Feature Request: Terminal Graphics Protocol Support (Sixel, Kitty, iTerm2)

Important Clarification

This feature request primarily targets the shell command execution mode (commands run with \! prefix or via the Bash tool). Users frequently need to visualize outputs from their development workflows:

# Current state: These commands fail or show errors
\!lsix *.png
\!viu --features=sixel plot.png
\!python visualize_metrics.py  # outputs matplotlib chart
\!gnuplot performance.gp       # generates 3D plot
\!dot -Tpng graph.dot  < /dev/null |  viu -    # renders graphviz diagram
!neato -Tpng network.gv | lsix  # renders network graph
!fdp -Tpng -o /tmp/fdp.png large_graph.gv && viu /tmp/fdp.png  # force-directed graph
!echo "digraph G { A -> B -> C; }" | dot -Tpng | viu -  # inline graphviz

Immediate Benefits (Shell Commands)

• View generated plots/charts without leaving Claude Code session
• Inspect image processing results inline
• Debug visual outputs during development
• Review data visualizations from analysis scripts
• Render architecture diagrams and flowcharts with graphviz

Future Potential: Visual Reasoning Capabilities

Beyond shell command support, terminal graphics could enable Claude to participate in visual analysis alongside users:

1. Performance Analysis: Read benchmark charts together, identify bottlenecks visually
2. Data Science Collaboration: Interpret 3D plots, statistical visualizations, ML model outputs
3. Architecture Reviews: Analyze system diagrams, flowcharts, dependency graphs
4. Debugging: Examine visual test outputs, coverage heatmaps, profiling flamegraphs

This would transform Claude Code from a text-only assistant to a visual collaborator, enabling richer human-AI interaction for data-heavy and visually-oriented development tasks.

The implementation should prioritize shell command support first, with the understanding that this infrastructure could later enable multimodal reasoning capabilities.

I would really like to see this implemented! I think it would reinforce the validity of Claude Code in the terminal!

I would love to have this! As more dev work moves to the CLI, features that eliminate context-switching are essential. Being able to instantly see visual outputs from Claude would be a huge win for keeping developers in a state of flow.

+1

+1

+1

+1

+1

+1

🖼️ Implementation Proposal: Terminal Image Preview Feature

I'd like to add my support for this feature and share a concrete implementation proposal.

Proposed Architecture

User attaches image
       ↓
[Terminal Capability Detection]
       ↓
┌──────────────────────────────────────┐
│ Check environment variables:         │
│ - $TERM_PROGRAM (iTerm.app, etc.)   │
│ - $KITTY_WINDOW_ID                  │
│ - $TERM (xterm-256color, etc.)      │
│ - Terminal response to XTGETTCAP    │
└──────────────────────────────────────┘
       ↓
[Select Protocol] → Kitty > iTerm2 > Sixel > Fallback
       ↓
[Display inline image with appropriate escape sequences]

Implementation Details

1. Terminal Detection (TypeScript)

interface TerminalCapabilities {
  supportsKitty: boolean;
  supportsIterm2: boolean;
  supportsSixel: boolean;
}

function detectTerminal(): TerminalCapabilities {
  const termProgram = process.env.TERM_PROGRAM;
  const kittyWindowId = process.env.KITTY_WINDOW_ID;
  
  return {
    supportsKitty: !!kittyWindowId || termProgram === 'WezTerm',
    supportsIterm2: termProgram === 'iTerm.app' || termProgram === 'WezTerm',
    supportsSixel: ['mlterm', 'xterm', 'foot', 'WezTerm'].some(
      t => process.env.TERM?.includes(t) || termProgram?.includes(t)
    )
  };
}

2. Protocol Implementation

| Protocol | Escape Sequence | Max Colors | Alpha |
|----------|----------------|------------|-------|
| Kitty | ESC_Gf=32,s=<w>,v=<h>;[base64]ESC\ | 16M | ✅ |
| iTerm2 | ESC]1337;File=inline=1:[base64]^G | 16M | ✅ |
| Sixel | ESCPq[sixel_data]ESC\ | 256 | ❌ |

3. Graceful Fallback
For unsupported terminals, keep the current [Image #N] clickable link behavior.

Use Cases

1. Screenshot debugging - See UI bugs inline
2. Chart/graph visualization - Data science workflows
3. Image diff review - Design changes in PRs
4. Diagram viewing - Architecture diagrams from tools like Mermaid

Existing Libraries

Consider using:

• Node.js: terminal-image, term-img
• Reference: WezTerm's implementation for multi-protocol support

Configuration Suggestion

{
  "terminal": {
    "imagePreview": {
      "enabled": true,
      "maxWidth": 80,
      "maxHeight": 24,
      "protocol": "auto" // or "kitty", "iterm2", "sixel", "none"
    }
  }
}

I believe this would significantly improve the developer experience, especially for:

• Debugging UI issues with screenshots
• Reviewing visual outputs from scripts
• Working with design assets

Happy to help with implementation if the team decides to move forward with this! 🚀

---
Comment generated with assistance from Claude Code

+1
optimizing Claude code output unrendered LaTeX formulas

+1

Dear claude-code developers, please do not hard-code against any terminal for detecting sixels support. Use DA1 or XTSMGRAPHICS to detect a supporting terminal, which is an increasing number lately.

And yeah, I'd love that feature to be available too, in claude-code. 😄

Another inspiration !
Working with Claude Code on STL files etc,
Claude Code or scripts can render with f3d tool and preview/show how looks like
( e.g. https://github.com/edu-samples/26Q1-3d-printing-model-from-code/blob/a08ff72a9f4ee37169c4ba8a322faafeba792f60/output/3d-examples/vesa-lightplate-75-4mm-iso-back-left.png
rendered using C++ f3d renderer https://github.com/edu-samples/26Q1-3d-printing-model-from-code/blob/fa16b68a16d885f9274979450427359d5bb50473/render_stl.py#L24
)
without leaving terminal when working on scripts!

So diagrams, charts, OCR/Scans preview, ML Charts etc previews, STL / 3D preview.. possibilities are endless :). (and on a top of it Claude Code can "see" images as well!

This would be great. I was just wanting to see a workflow as graphviz using the kitty graphics format and Claude wasn't able to do it today.

<img width="2319" height="203" alt="Image" src="https://github.com/user-attachments/assets/5ea0917f-b0f5-4760-9f79-03759fb836ae" />

This is an actually practical usecase. It would be nice to actually show the screenshot rather than [Image #1] :-)

I'd love to use this for data vis problems, allowing claude to inline charts in its responses to me when I'm discussing a problem

+1

+1

+1

+1 on this. I'm using Ghostty which supports the Kitty graphics protocol natively.

My use case: I use Claude Code to generate images (charts, diagrams, UI mockups via PIL/Pillow), and currently the only way to view them is to either:

1. Run open file.png to open in Preview (breaks flow)
2. Exit Claude Code and run the display script manually in the shell

I tried setting up a PostToolUse hook that writes to /dev/tty to bypass Claude Code's stdout capture — it partially works but is fragile.

The ideal solution would be for Claude Code to pass through Kitty/Sixel escape sequences to the terminal instead of stripping them. Even a simple "render image at path" built-in command would be a huge improvement for terminals that support graphics protocols (Ghostty, Kitty, WezTerm, iTerm2).

I'm using Claude Code in VS Code's terminal mode with a 1M context window (Opus 4.6). My main use cases for inline image rendering:

• Viewing generated charts/diagrams without breaking flow (open file.png disrupts the conversation)
• Verifying screenshots Claude analyzes — currently I can't see what Claude sees
• Reviewing visual diffs of UI changes

Running on macOS with terminal.integrated.enableImages: true in VS Code, which supports Sixel/Kitty since v1.110 — the terminal side is ready, just waiting for Claude Code to pass through the graphics.

Would love this both in the terminal and in the VS Code extension's graphical panel, as suggested by @JannikLohausComuneo.

+1

Hi @antrewmorrison, I just noticed that this was closed and I'm curious: does this mean this feature will be included in an upcoming release of Claude Code, or is it not planned? Thanks!

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.