TermCanvas: an infinite canvas for terminals and coding agents
An infinite canvas desktop app for visually managing terminals
At a glance
- What is it?
- TermCanvas is an MIT-licensed Electron desktop app that arranges terminals and AI coding agents on a pannable, zoomable canvas, with a Project to Worktree to Terminal hierarchy and a bundled CLI. It is a spatial alternative to tabs and split panes, with the trade-offs that implies.
- Who is it for?
- Adopt TermCanvas if you routinely run several coding agents across git worktrees and lose track of which terminal is doing what; the status dots, session replay, and the termcanvas CLI are built for exactly that. Skip it if you want a plain multiplexer over SSH, if you need a signed macOS build, or if you cannot tolerate a fast-moving 0.39.x line.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 107 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem TermCanvas targets: too many agent terminals, no spatial memory
Terminal multiplexers give you panes and windows. They do not give you a place. Once you are running Claude Code, Codex, or a shell in three worktrees at the same time, the usual failure is not that the terminals do not exist but that you cannot remember which one is which. TermCanvas answers that with an infinite canvas: terminals are tiles you drag, zoom, and group, and the README states the goal as spreading all your terminals across a spatial canvas with no tabs and no split panes. The audience is narrow and specific. It is a developer running multiple AI coding agents across git worktrees on a single machine, who wants to see the whole working set at once rather than cycle through a window list. If your work is one shell in one repository, the canvas is overhead with no payoff.
The Project, Worktree, Terminal hierarchy and how the canvas stays in sync
The organising model is a three-level tree: projects contain worktrees, worktrees contain terminals. According to the README, adding a project makes TermCanvas auto-detect its worktrees, and creating a new worktree from the terminal makes it appear on the canvas instantly. That is the part worth paying attention to. A canvas that requires manual placement of every new pane decays into clutter within a day; here, new worktrees are added to the structure without a drag. The README also describes saving an entire layout to a .termcanvas file, which implies the arrangement is serialisable rather than ephemeral. The CLI mirrors the same hierarchy with project, worktree, and terminal groups, so the on-disk model and the GUI model are the same thing rather than two parallel abstractions. Terminals come in three kinds alongside agents: shell, lazygit, and tmux. That last one matters if you already have a tmux workflow, because it means TermCanvas can host it instead of replacing it.
How you get it running, and the macOS packaging gotchas
The documented path is a download from GitHub Releases. The README carries an explicit warning about macOS builds: files with arm64 in the filename are native Apple Silicon builds, while files without it are Intel x64 builds that still launch on M-series Macs through Rosetta 2 but show noticeable lag when panning and zooming. The stated verification method is to open Activity Monitor, find TermCanvas, and check the Kind column for Apple rather than Intel. Unsigned builds may be blocked or reported as damaged, and the README gives the fix: xattr -cr /Applications/TermCanvas.app. Building from source uses pnpm, with pnpm-lock.yaml as the canonical lockfile: git clone the repository, then pnpm install, then pnpm dev. After launching, Settings, General, Command line interface, Register adds termcanvas and hydra to your PATH. That registration step is not cosmetic: the README says it also installs TermCanvas skills and lifecycle hooks for Claude and Codex, and that for Codex 0.129.0 and newer it writes the required hook trust state into ~/.codex/config.toml. If you skip Register, you lose the CLI and the lifecycle events that feed the rest of the app.
The termcanvas CLI is the part that outlives the GUI
The README lists the command surface in full. Groups are project (add, list, remove, rescan), worktree (list, create, remove), terminal (create, list, status, output, destroy, set-title), workflow, telemetry (get, events), pin (add, list, show, update, rm), diff, and state. Concrete shapes include project add <path>, worktree create --repo <path> --branch <name> with an optional --from <ref>, and terminal create --worktree <path> --type <claude|codex|shell|...> with optional --prompt, --parent-terminal, and --auto-approve flags. terminal output <id> returns the last N lines with a default of 50, and telemetry get --terminal <id> or telemetry get --workflow <id> --repo <path> exposes usage data. state dumps the full canvas as JSON. Two details stand out. The --parent-terminal flag implies terminals can be nested or chained, which is how a lead agent dispatching to workers would be modelled. The workflow group is described as a Lead-driven Hydra workflow over HTTP, so orchestration is intended to be scriptable from outside the app rather than clicked through. If you only ever use the GUI, the CLI is still the escape hatch for scripting and for reading state without a screenshot.
Where TermCanvas is the wrong tool
The README is honest about one limitation and silent about others. The honest one is the arm64 build: on an M-series Mac, running the Intel build works but pans and zooms poorly, and the fix is a manual redownload rather than an in-app prompt. The silent ones are more consequential. TermCanvas is an Electron desktop app, so it assumes a local graphical session; there is no documented remote or headless mode, and tmux support means hosting tmux inside the app rather than attaching to a tmux server over SSH. If your workflow is terminal-first over SSH, this is the wrong layer. The macOS build is unsigned, which the README treats as expected and works around with xattr rather than a notarisation step; on a managed machine where you cannot clear quarantine attributes, the app may simply not launch. Version numbering is also a signal: the release list shows v0.39.10, v0.39.9, and v0.39.8, with the two most recent published the same day. That is a fast-moving pre-1.0 line, and the Codex hook trust behaviour in ~/.codex/config.toml depends on a specific Codex version, so a mismatch between your Codex release and TermCanvas can change what telemetry you actually receive.
TermCanvas versus tmux plus a terminal emulator
The nearest alternative is not another canvas app. It is tmux inside whatever terminal emulator you already use. The difference in approach is structural. tmux organises sessions, windows, and panes in a fixed grid that you navigate by keystroke; it is text-only, runs over SSH, and survives disconnection. TermCanvas organises the same terminals in two-dimensional space with zoom, box-select, and free-form annotation, and it layers agent-specific state on top: a coloured dot per tile indicating thinking, awaiting input, idle, or done, inline diff cards for reviewing an agent's edits, and a sessions panel that lists every past Claude or Codex conversation by project and worktree, with click-to-replay. tmux gives you none of that and does not try to. The honest framing is that these solve different halves of the problem. tmux solves persistence and remote access. TermCanvas solves knowing what six agents are doing at a glance. If you need both, the README's own tmux terminal type suggests running tmux inside a TermCanvas tile, which is a reasonable composition but not a replacement.
Licence, maintenance, and what a 0.39.x cadence costs you
The licence is MIT, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are preserved. That is the permissive end of the spectrum and the practical consequence is that you can vendor or fork it without a copyleft obligation; it is not legal advice, and if you redistribute a modified build you should read the LICENSE file for the exact notice requirements. The maintenance picture from the supplied material is a project under active development rather than a stable platform: three releases in the visible window, two of them within eight hours of each other on 2026-05-31, and a version number still below 1.0. The README documents in-app auto-update, so the upgrade path is not manual, but the upgrade cost is real in a different way. Features described in the README, including the Codex hook trust state in ~/.codex/config.toml and the Claude and Codex lifecycle hooks installed by the Register step, couple TermCanvas to the internals of those agent CLIs. When Claude Code or Codex changes its hook format, TermCanvas has to follow. Budget for that coupling, and check the release notes for the version you are installing rather than assuming the hooks still fire.
Editorial conclusion
Adopt TermCanvas if you routinely run several coding agents across git worktrees and lose track of which terminal is doing what; the status dots, session replay, and the termcanvas CLI are built for exactly that. Skip it if you want a plain multiplexer over SSH, if you need a signed macOS build, or if you cannot tolerate a fast-moving 0.39.x line. Before relying on it, verify the arm64 versus Intel labelling on the release asset, the quarantine step for unsigned macOS builds, and whether your Codex version is 0.129.0 or newer so the hook trust state written to ~/.codex/config.toml applies.
Community notes