Terminal image rendering

gh stories only ever draws a real image inline through a terminal graphics protocol it has actually implemented. Two, currently: the Kitty graphics protocol and iTerm2's inline images protocol. Everywhere else, it is honest about the gap and opens the image in your system's default viewer instead of approximating it with block characters or skipping it silently.

Image rendering by terminal
TerminalImageVideoStatus
kittyInline, via the Kitty graphics protocolPoster frame inline; playback opens externallyInline
iTerm2 (macOS)Inline, via the iTerm2 inline images protocolPoster frame inline; playback opens externallyInline
Everything else — Terminal.app, Windows Terminal, tmux, VS Code’s integrated terminal, and any terminal not listed aboveOpens in your default image viewer instead of drawing inlineOpens in your default player; no poster frame is drawn inlineFallback

Video is never drawn as inline motion in any terminal, anywhere — only a real still poster frame (inline where supported, opened externally where not), plus a command to open the actual video in an external player. That claim does not change based on which terminal you use.

This table is proved by captured runs of the real CLI against real terminals (seemise run capture in the repository), not by descriptions on this page. Thebrowser sample demo simulates the terminal's visual frame for comparison only and is not evidence of terminal rendering.

Browser extension

Manual install everywhere, for now — see the install page for exact steps.

Browser support
BrowserInstallStatus
ChromeManual — Load unpacked from the release archiveManual install
EdgeManual — Load unpacked from the release archiveManual install
FirefoxManual — Load Temporary Add-on; unsigned, reload each sessionManual install
SafariNo build existsNot supported

None of the above is published in an extension store yet. There is no compatibility claim beyond what is in these two tables — see the currentimplementation checklist for what is still in progress.