Inline Graphics

The terminal renders images inline, in three protocols:

Protocol	Sequence	Notes
iTerm2	OSC 1337 ; File=...	The most widely supported by CLI tooling
Sixel	DCS q ... ST	The classic DEC protocol; wide support in image tools
Kitty	APC _G ... ST	Supports z-index placement above or below text

Why a terminal needs this

Because the agent needs a way to show you something. A render, a graph, a diff of two screenshots, a texture it just generated — describing those in prose wastes both your time. An image in the shared surface is the shortest path from “the agent knows” to “you know.”

It is also why the graphics stack is in a product that frames itself as a chat surface: this is the agent presenting itself to the human, which is exactly what the terminal is for.

Sizing

Images can carry explicit dimensions or be left to their intrinsic size.

• Unsized images (Sixel, and iTerm by default) are drawn at their true pixel resolution rather than stretched onto the cell grid, so a 64×64 icon looks like a 64×64 icon.
• Explicitly sized images honour what the protocol asked for. iTerm’s width=20 (cells), width=200px, width=50% and width=auto are all understood, as is the preserveAspectRatio flag, which defaults to on.
• Kitty z-index is respected: negative values sit below the text layer, zero and above sit on top.

Trying it

Any tool that already emits one of these protocols works. For a quick check, chafa with Sixel output, or an iTerm-protocol image printer such as imgcat:

chafa --format=sixel .\Content\Textures\T_Poster.png

If you get a block of garbled escape characters instead of a picture, the tool is emitting a protocol variant the decoder did not recognise — that is worth reporting, with the tool and command line.