How
Claude Code skills instruct the agent to run the Bun CLI (spawn/show) with JSON config; the controller can send `update` with a new config over the socket. tui-canvas wraps the same idea as an MCP server.
Claude Canvas
Prebuilt Ink TUI canvases Claude Code spawns in tmux panes.
repo ↗docs ↗tui-canvas (Czaruno), framework-agnostic MCP port ↗tui-canvas (jredville), Go persistent markdown canvas ↗
- license
- MIT. README: 'This is a proof of concept and is unsupported.'
- language
- TypeScript (Bun, Ink 6, React 19)
- backing
- Individual (David Siegel, GitHub dvdsgl)
- stars
- 1,512 (as of 2026-10-09)
- first release
- 2026-01
ignore
A dormant demo whose one good idea (awaitable human choice) is easy to borrow; it is not a foundation.
Ignore it for this purpose.
the steelman: the best honest case for it
claude-canvas proved the demand in one week: 1.5k stars for the simple idea that a coding agent deserves its own display next to the chat, in the terminal, with real interaction (pick a meeting slot, select text to edit, choose a seat) rather than more scrolling text. Its design is pleasingly small: a skill, a CLI, a tmux split and a six-message socket protocol, with a typed async API that turns a canvas into a function call that returns the human's choice. That 'canvas as an awaitable question to the human' pattern is exactly what agents need for approvals and choices, and it works in any tmux today with no new terminal or framework.
scores
| UI as data | 2 scene 5 | only the config is JSON; each canvas is hand-written Ink code |
|---|---|---|
| Agent can drive it | 3 scene 5 | CLI + socket protocol for spawn/update/close of prebuilt canvases |
| Agent can see it | 1 scene 5 | selection events only, no screen or state read |
| Small, targeted edits | 2 scene 5 | whole-config update messages |
| Time travel | 0 scene 0 | |
| Live data rate | 1 scene 5 | ad hoc config pushes; no data sources |
| Terminal native | 5 scene 5 | |
| Pixel graphics | 0 scene 4 | |
| Teaching | 0 scene 3 | |
| Maturity | 1 scene 1 | self-described unsupported proof of concept, dormant since Jan 2026 |
| Openness | 4 scene 4 |
Claude Canvas scene now scene planned
how agents use it
Wiring it in
Install the plugin (/plugin marketplace add dvdsgl/claude-canvas); needs Bun and a tmux session. New canvas kinds require writing Ink components.
Seeing the result
Only the user's result comes back (selected/cancelled events with data). The agent cannot read the rendered screen or canvas state.
Small edits
No; `update` replaces the canvas config wholesale.
History
None.
In short
A pleasant demo of 'give the agent a second screen', but the agent is limited to choosing among prebuilt canvases and receiving a selection.
architecture
A Claude Code plugin (marketplace + skills) plus a Bun CLI. `canvas spawn <kind> --scenario <name> --config '<json>'` opens a prebuilt Ink/React canvas (calendar, document, flight) in a tmux split pane. The canvas and the controller talk over a Unix domain socket: canvas to controller sends ready/selected/cancelled/error; controller to canvas sends update(config)/close/ping. A TypeScript high-level API (pickMeetingTime, editDocument, bookFlight) spawns a canvas and awaits the user's selection.
- Fixed catalogue of hand-written canvases; the agent picks kind + scenario and supplies JSON config
- IPC over a Unix socket with a tiny message vocabulary (update/close/ping; ready/selected/cancelled/error)
- Delivered as Claude Code skills that teach the model the CLI
- Mouse support inside canvases; tmux is required
- tui-canvas (Czaruno, 0 stars, MIT, Jan 2026) ports the idea to an MCP server with a protocol-first design and OpenTUI/Ink implementations; jredville/tui-canvas (0 stars) is a Go persistent markdown canvas with a socket daemon
performance
No published numbers.
adoption and upkeep
Adoption
1.5k stars and 138 forks gathered in its launch week (Jan 2026, shared widely on X/LinkedIn), then no further commits. No known production users; no releases.
Maintainability
A launch-week demo that was never maintained after; treat as an idea, not a dependency.
Releases: No GitHub releases; 19 commits total, all between 2026-01-06 and 2026-01-08 · Contributors: 3 · Recent: None since 2026-01-08 (last push) · Bus factor: low: dormant single-author proof of concept
weaknesses
- Self-described unsupported proof of concept; no commits since 2026-01-08
- Fixed set of three canvases; new UIs require writing React/Ink code
- No readback of the screen or state; agent only receives the final selection
- Requires tmux and Bun
- tui-canvas forks have zero stars and little activity
and thc-scene
Overlap
An agent opens a terminal UI beside the conversation and exchanges messages with it over a Unix socket.
What scene would be reinventing
Nothing substantial; scene already exceeds it. The awaitable 'ask the human and wait for selected/cancelled' round trip is the one thing done cleanly here.
The gap it leaves
claude-canvas has no UI-as-data, no readback, no patches, no data streams, no history, no pixels; thc-scene does all of these.
What to borrow
- An awaitable high-level call (e.g. scene.ask(ui) -> {selected, data} | {cancelled}) for approvals and pickers
- Ship the agent integration as a Claude Code plugin/skill with a marketplace entry
- Spawn into a tmux/herdr split automatically when available
sources
- dvdsgl/claude-canvas README github.com
- claude-canvas canvas SKILL.md github.com
- claude-canvas canvas-api.ts github.com
- GitHub API repos/dvdsgl/claude-canvas api.github.com
- Czaruno/tui-canvas README github.com
- jredville/tui-canvas github.com