nodeterm: tmux-backed terminals and parallel AI agent sessions on an infinite canvas
Node-based terminal manager for AI coding agents — tmux-backed terminals and parallel agent sessions as draggable nodes on an infinite pan/zoom canvas. macOS, Linux, and a browser Server Edition.
At a glance
- What is it?
- nodeterm is an Electron app that places real tmux terminals and coding-agent sessions as draggable nodes on a pan/zoom canvas, with a kanban board view of the same sessions. This article covers what it does, how the three surfaces share one service layer, and where the design gets in your way.
- Who is it for?
- Adopt nodeterm if you routinely run several coding-agent sessions at once and lose track of which shell is where, and you are willing to accept a BUSL-1.1 licence and an Electron desktop app whose macOS build ships its own tmux. Do not adopt it if you need a permissively licensed tool, a headless-only workflow, or a stable plugin API, none of which the README or package.json describes.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem nodeterm addresses: terminal tabs hide which agent is waiting
Terminal multiplexers organise sessions as a list. You switch between them, and the one you are not looking at becomes invisible. That is fine when a session is a shell prompt. It stops being fine when each session is a coding agent that can pause mid-turn to ask for permission. The README states the motivation plainly: stacked terminal tabs hide context, and you lose track of what is running where.
nodeterm's answer is spatial. Every terminal and every agent is a node on a single canvas you can pan and zoom, so position carries meaning. You can group nodes, label them, and place a sticky note next to an agent to feed it context. The README names people with ADHD and scattered workflows as the intended audience, and the topics list includes adhd alongside agent-orchestration and terminal-multiplexer. That is a specific audience, not a general one: if you are comfortable with tmux windows and a tiling window manager, the canvas may be more surface area than you want.
How nodeterm works: tmux sessions behind a canvas, and a second view of the same sessions
The mechanism is tmux. According to the README, each terminal or agent node runs in its own persistent tmux session. That is what makes sessions survive node remounts and full app restarts, including running processes. After a machine reboot, the README says scrollback is restored and agent sessions resume through `claude --resume`. The macOS app ships its own tmux, so continuity works without a system install; a tmux already on your system is preferred over the bundled one. Terminals opened before an upgrade keep the old binary until you refresh the node, which is a real behavioural edge.
Agent status is the other half. The README says status is hook-driven rather than scraped from output, which produces RUNNING and NEEDS YOU badges, subagent cards with live transcripts, a per-node context meter, and OS notifications. Clicking a notification lets you answer a permission prompt inside the node.
The same project is also a kanban board. Cards are live sessions, not references to them: you drag a card between columns while the agent keeps running, and the card modal shows the real session with members, due date, priority and comments. The README gives `⌘⇧B` as the toggle. The three surfaces (desktop app, self-hosted browser Server Edition, iOS companion) are described as running on the same service seam, which is why a phone can attach to a session already running on the desktop.
Installing nodeterm and opening your first agent node
The README points to the releases page for installers and to nodeterm.dev/docs for full documentation. The badge line lists macOS arm64 and x64, Linux x64, and Windows x64 as beta. If you prefer to build from source, the repository's package.json defines the scripts. Node must satisfy the engines field: `^22.22.2 || ^24.15.0 || >=26.0.0`.
npm ci
npm run dev`npm run dev` runs `electron-vite dev`, which starts the Electron app with hot reload. The first launch is where you should expect native module work: package.json has a `rebuild` script that runs `scripts/patch-node-pty.mjs` and then `electron-rebuild -f -w node-pty,smart-whisper`. If node-pty fails to load, that is the script to run.
Once the canvas is up, the README describes the entry point: right-click the canvas to open a terminal or an agent. The agent list in the README is Claude Code, Codex, Gemini, GitHub Copilot, opencode, Grok, and custom. Pick one and a node appears. Because the node is backed by tmux, you can quit the app and reopen it and the session should still be there. To see the board view of the same sessions, press `⌘⇧B`.
If you want the browser surface instead, the Dockerfile builds it. Note the comment in that file: the server runs under plain `node`, while the repo's postinstall compiles node-pty against Electron's ABI, so the image uses `--ignore-scripts` and an explicit `npm rebuild node-pty`.
npm run server:build
npm run server:startThe Dockerfile notes that the server refuses a non-loopback bind unless `--insecure-http` is passed, and that it sets the Secure cookie flag itself when the proxy forwards `X-Forwarded-Proto: https`. It also states plainly: do not publish the container port directly on a public interface.
Where nodeterm gets in the way: tmux coupling, ABI traps and a thin public API
The tmux dependency is the main structural constraint. Session continuity is the headline feature, and it is tmux that provides it. The Dockerfile says that without tmux, PtyManager falls back to a plain shell. So in a container image built without the tmux package, you keep the canvas and lose the persistence that justifies the canvas. On hosts where you cannot install tmux and the bundled binary does not apply (Linux and Windows, where the README only claims a bundled tmux for macOS), you are relying on whatever is already there.
The native module story is the second trap, and the Dockerfile is unusually candid about it. node-pty must be compiled against the ABI of whatever runtime loads it: Electron for the desktop app, plain Node for the server. The image keeps deps and runtime stages on the same Node major for that reason. If you build a custom image or change the Node version, expect a NODE_MODULE_VERSION mismatch at boot rather than a helpful error.
Third, the licence. The README badge and package.json both say BUSL-1.1, while the repository metadata reports NOASSERTION. Those disagree, and the LICENSE file is the only thing that settles it. Treat the badge as a signal, not a legal answer.
Finally, extensibility. The README lists custom agents and agents that can drive the canvas, but it does not document a plugin API or a stable extension point. If your plan is to build on nodeterm rather than use it, the documentation does not currently support that plan.
nodeterm compared with plain tmux plus a tiling window manager
The honest alternative for most of this feature set is tmux itself, driven from a tiling window manager or a terminal emulator with splits. The difference is not capability, it is where state lives. tmux keeps sessions in a server process and exposes them through a text interface: `tmux attach`, `tmux ls`, key bindings. nodeterm keeps sessions in the same kind of server process but puts a GUI canvas on top, and adds two things tmux does not have: a status layer that knows an agent is waiting for input, and a kanban board whose cards are the live sessions.
That second layer is the actual product. If you already run four agents in four tmux panes and you never lose one, tmux plus your window manager costs less memory, has no Electron runtime, and has no ABI problems. If you lose agents, or you want the same session on your phone, nodeterm is solving a problem tmux does not attempt. The README's phone pairing claim is specific: one QR code scanned with the nodeterm iOS app, with the session continuing over a relay and end-to-end encrypted rather than only on the LAN. That is a different product category from a terminal multiplexer.
Maintenance, release cadence and what the licence means for you
The repository is not archived, and the last push was on 2026-09-10, the same day as the v0.3.5 release. Before that, v0.3.4 landed on 2026-08-30 and v0.3.3 on 2026-08-28. Three releases in under two weeks suggests active work, and the version in package.json is 0.3.6, one ahead of the newest published release, which is normal for a main branch between tags.
The upgrade cost has a specific shape here. Because terminals are tmux sessions, upgrading the app does not automatically move existing terminals onto a new bundled tmux: the README says terminals opened before an upgrade stay as they were until you refresh the node. So an upgrade is not purely a binary swap; you decide per node when to take the new runtime.
On licensing, the README badge and package.json both name BUSL-1.1, which is a source-available licence rather than an OSI-approved open source one. The repository metadata reports NOASSERTION, so the machine-readable field does not confirm the badge. Read LICENSE before you build anything commercial on top of this. This is a description of what the files say, not legal advice.
Editorial conclusion
Adopt nodeterm if you routinely run several coding-agent sessions at once and lose track of which shell is where, and you are willing to accept a BUSL-1.1 licence and an Electron desktop app whose macOS build ships its own tmux. Do not adopt it if you need a permissively licensed tool, a headless-only workflow, or a stable plugin API, none of which the README or package.json describes. Before committing, verify three things yourself: that your Node version satisfies the engines field (^22.22.2, ^24.15.0 or >=26.0.0), that tmux behaves as you expect on your platform, and that the Server Edition container is only reachable behind a reverse proxy, since the Dockerfile warns against publishing the port directly.
Frequently asked questions
What is a node terminal in nodeterm?
In nodeterm, a node is a single item on the canvas: a terminal, an agent session, a sticky note, a group, a Monaco editor, a diff view, or a web or video panel. Each terminal or agent node runs in its own persistent tmux session, so it survives node remounts and full app restarts.
Does nodeterm use Node.js, and which version do I need?
nodeterm is written in TypeScript and its package.json sets an engines field of ^22.22.2 || ^24.15.0 || >=26.0.0. The desktop app runs under Electron while the Server Edition runs under plain Node, and the Dockerfile notes that node-pty must be compiled against the ABI of whichever runtime loads it.
How do I install and run nodeterm from source?
The README points to the releases page for installers and to nodeterm.dev/docs for documentation. From a clone, package.json defines npm run dev, which runs electron-vite dev, and npm run rebuild, which patches and rebuilds the node-pty and smart-whisper native modules if they fail to load.
What licence does nodeterm use?
The README badge and package.json both state BUSL-1.1, while the repository metadata reports NOASSERTION. The LICENSE file is the authoritative source, and BUSL-1.1 is a source-available licence rather than an OSI-approved open source one.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/eneskirca-nodeterm)