TermCanvas: an infinite canvas for terminals and AI coding agents

The problem TermCanvas is aimed at: too many agent sessions, no spatial memory

A developer running three Claude Code sessions across two git worktrees, plus a shell and lazygit, has roughly six panes competing for one window. Tabs and split panes give each pane a name, not a position, so switching costs a mental lookup every time.

TermCanvas answers with space. The README describes the app as spreading "all your terminals across an infinite spatial canvas, no more tabs, no more split panes". Terminals become draggable tiles you can zoom into for focus or zoom out from to see the whole arrangement.

The target user is narrow but real: someone orchestrating multiple AI coding agents rather than editing one file at a time. The repository topics include agent-orchestration, claude-code and git-worktree, and the README states first-class support for Claude Code, Codex, Kimi, Gemini and OpenCode. If you run one shell and one editor, the canvas is overhead. If you run five agents and cannot remember which one is waiting for input, the spatial layout is the feature.

Project, worktree, terminal: the three-layer model behind the canvas

The hierarchy is Project, then Worktree, then Terminal, and the README says it mirrors how you actually use git. Adding a project makes TermCanvas auto-detect its worktrees. Creating a worktree from the terminal makes it appear on the canvas, and the README states new worktrees appear automatically as you create them.

Each terminal tile carries a coloured status dot indicating whether the agent is thinking, awaiting input, idle or done. That is the mechanism that makes a zoomed-out canvas readable: you are not reading text, you are reading state.

The app bundles two CLIs, termcanvas and hydra, and the termcanvas command exposes the same model programmatically. Groups include project (add, list, remove, rescan), worktree (list, create, remove), terminal (create, list, status, output, destroy, set-title), workflow, telemetry, pin, diff and state. So the canvas is not the only interface: a script can create a terminal with terminal create --worktree <path> --type <claude|codex|shell|…> and read its output with terminal output <id> --lines N, where the default line count is 50. The state group dumps the full canvas as JSON.

On the desktop side, the main process entry is dist-electron/main.js and the renderer is built with Vite. The repository also contains headless-runtime, server, electron, cli, hydra and skills directories, so the terminal layer is separable from the Electron shell.

Installing TermCanvas and running a first agent terminal

The README points to GitHub Releases for the latest build. On Apple Silicon, the filename matters: files with arm64 in the name are native M-series builds, and files without it are Intel builds that still launch through Rosetta 2 but lag when panning and zooming. The README suggests verifying via Activity Monitor, where the Kind column should read Apple rather than Intel.

If macOS blocks an unsigned build, the README gives one command to clear the quarantine attribute:

xattr -cr /Applications/TermCanvas.app

Replace the path if the app lives elsewhere. The README does not document a signed or notarised installer, so treat this step as expected rather than exceptional.

Building from source uses pnpm, and pnpm-lock.yaml is the canonical lockfile:

git clone https://github.com/blueberrycongee/termcanvas.git
cd termcanvas
pnpm install
pnpm dev

After the app launches, the README instructs you to open Settings, then General, then Command line interface, and click Register. That adds termcanvas and hydra to your PATH and also installs TermCanvas skills and lifecycle hooks for Claude and Codex. For Codex 0.129.0 and newer, the README states TermCanvas writes the required hook trust state into ~/.codex/config.toml so the generated hooks are reviewed and trusted and keep emitting terminal lifecycle and telemetry events.

With the CLI registered, the README's own usage shapes show how to drive a terminal from a shell. Listing worktrees and creating an agent terminal follow these forms:

termcanvas worktree create --repo <path> --branch <name> [--from <ref>]
termcanvas terminal create --worktree <path> --type <claude|codex|shell|…>
termcanvas terminal output <id> [--lines N]

The first command creates a worktree from a repository path and branch, with an optional starting ref. The second creates a terminal of a given type inside a worktree. The third reads a terminal's output, and the README notes the default is 50 lines. The same reference also documents terminal create --prompt <text>, --parent-terminal <id> and --auto-approve; leaving --auto-approve off means the agent still asks for approval, which is the safer default for a first run.

Where TermCanvas gets in the way

The macOS packaging is the sharpest limitation. An unsigned build that macOS reports as damaged, plus a manual xattr -cr step, is friction that a signed installer would remove, and the README does not describe notarisation. Windows and Linux users get no equivalent warning, but the README also gives no platform-specific install notes for them beyond the release downloads.

There is an architectural cost to the Electron shell. The canvas, the diff cards, the sessions panel and the usage tracking all live in the same app, so the memory floor is that of a Chromium application, not a terminal emulator. If your workflow is one shell plus tmux, that overhead buys you nothing.

The AI-agent features are also tied to specific CLIs. The README names Claude Code, Codex, Kimi, Gemini and OpenCode, and the lifecycle hooks it installs target Claude and Codex specifically. An agent not on that list can still run as a shell terminal, but it will not get the status dot or the session replay, because those depend on the hook and session data the app understands.

Finally, the usage tracking signs in to sync across devices, and the .env.example file shows the app talks to Supabase through VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY. That is an optional cloud dependency, but it is a cloud dependency: if you never sign in, the README does not say what stays local.

TermCanvas compared with tmux and a tiling window manager

tmux solves a similar problem with a different primitive. Its unit is the pane inside a session, addressed by name and index, and it survives disconnection because it runs as a server. TermCanvas does not describe itself as a detachable session server; its unit is a tile on a canvas, and the persistence it advertises is layout persistence to a .termcanvas file plus session replay for past Claude and Codex conversations.

That difference decides the choice. If you work over SSH and need sessions that outlive your connection, tmux is the right tool and TermCanvas is not, because the README does not claim remote or detachable sessions. If you work locally with a GUI, several agents and git worktrees, tmux gives you no spatial overview and no agent status, while TermCanvas gives you both.

A tiling window manager is the closer alternative, since it also arranges real terminal windows. The difference is that a tiling WM arranges windows by rule, while TermCanvas arranges tiles by hand and persists that arrangement per project. Hand placement is worse for reproducibility and better for the case where the layout encodes which agent belongs to which worktree.

Licence and the cost of keeping up with a fast release line

TermCanvas is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. The README and repository do not state any additional terms, and the app bundles no separate licence for the CLI beyond the repository licence. This is a description of the licence file, not legal advice; if you redistribute a modified build, read LICENSE yourself.

The release cadence is the practical maintenance cost. The version in package.json is 0.39.10, and the release list shows 0.39.10 on 2026-05-31, 0.39.9 on 2026-05-31 and 0.39.8 on 2026-05-18. Patch releases landing twice in one day suggest active iteration, and the README advertises in-app auto-update, so the app can move underneath you. The last push to the repository was on 2026-05-31, so the project has been quiet for months rather than actively developed right now.

For a source build, pnpm-lock.yaml is the canonical lockfile, so pinning to a tag and installing from that lockfile is the reproducible path. The README does not document a rollback procedure if an auto-update breaks your layout, so keep the .termcanvas layout file under version control if the arrangement matters to you.

Editorial conclusion

TermCanvas suits developers who already run several Claude Code or Codex sessions across git worktrees and lose track of them in tabs, and who are comfortable with an unsigned macOS build or a pnpm source build. Skip it if you want a plain multiplexer with no Electron layer, or if you need a signed, notarised macOS installer, which the README does not claim to provide. Before adopting it, verify three things: that you downloaded the file with arm64 in its name, that Activity Monitor reports the app's Kind as Apple, and that Settings, General, Command line interface registers termcanvas and hydra on your PATH.

Frequently asked questions

Official sources

1. blueberrycongee/termcanvas on GitHub
2. License: MIT
3. Project website
4. README
5. Releases