nodeterm: tmux-backed terminals and AI agents as nodes on a canvas

The problem is spatial memory, not terminal emulation

Terminal multiplexers solve persistence. They do not solve orientation. When five agent sessions run at once, each waiting on a different permission prompt, a tab bar gives you five identical labels and no sense of which one is blocked. nodeterm's answer is a canvas: the README describes terminals and agents as draggable nodes on a single pan/zoom surface, with grouping, labels and zoom. The stated audience is explicit, people with ADHD and scattered workflows, and the pitch is that a spatial layout replaces a stack of hidden tabs. That framing is honest about the trade-off. A canvas costs screen space and mouse travel, and it only pays off when you actually hold several concurrent sessions. If you run one shell at a time, the node metaphor is overhead rather than structure.

What actually runs underneath: tmux plus an Electron shell

The persistence layer is tmux, not a custom process manager. According to the README, each terminal and agent runs in its own persistent tmux session, so nodes survive remounting and full app restarts, including live processes. After a machine reboot, the app restores scrollback and resumes agent sessions with a command in the shape of claude --resume. The macOS build ships its own tmux, so the feature works with nothing installed, but a tmux already present on the system is used in preference to the bundled one. That preference is worth knowing: your local tmux configuration and version become part of the runtime. The terminal surface is xterm, the editor node is Monaco, and the shell is Electron with a service seam that the README says lets the same canvas run as a desktop app, a self-hosted browser app (Server Edition) and an iOS companion attaching to the same live sessions. Agent status is hook-driven rather than scraped from output, which is the more reliable of the two approaches: the agent reports its own state, and the UI renders RUNNING or NEEDS YOU badges, subagent cards with transcripts, and a per-node context meter.

The kanban view is the same sessions, not a separate tracker

Each project is both a canvas and a kanban board, toggled with a keyboard shortcut the README gives as Cmd+Shift+B. The cards are the live sessions, so dragging a card between columns does not stop the agent. Opening a card gives a modal containing the real session plus members, due date, priority and comments. This is the part that distinguishes nodeterm from a terminal with a notes panel. The board is not a mirror that drifts from reality; there is only one session object, rendered two ways. It also means the board inherits the canvas's weaknesses. If a session dies or the tmux server is not reachable, the card is a card with nothing behind it, and the README does not describe a fallback rendering for that case.

Getting it running, and the config that matters

The README points at prebuilt installers for macOS (arm64 and x64), Linux (x64) and Windows (x64, beta), with .dmg, .AppImage, .deb and Setup .exe assets across releases, plus a Build from source section and a separate docs site at nodeterm.dev/docs. The concrete behaviour to plan around is the tmux resolution order: the bundled tmux on macOS is a fallback, and a system tmux takes precedence. The README also notes that terminals opened before an upgrade stay as they were until you refresh the node, which is the kind of detail that explains a confusing bug report after every release. Node kinds are created from a canvas right-click rather than a menu, and the documented kinds are terminal, agent, sticky note, group, editor, diff and web/video. Groups can be bound to a git worktree, which is how the README suggests running one agent per branch. Dictation is hold Cmd+Option, on-device Whisper, then an explicit Send, with nothing auto-submitted.

Where it breaks down

The Windows build is labelled beta in the README's own platform badge, so treat it as untested ground. The remote story is narrower than the marketing line suggests: phone pairing is described for the iOS companion app specifically, and the browser Server Edition is a separate deployment of the same canvas rather than a way to open your desktop session from a browser tab. The app is Electron, with the memory and startup cost that implies, and the canvas is a rendering surface that has to stay responsive while several terminal emulators paint inside it. There is no evidence in the supplied material of a headless mode, a CLI, or any way to drive nodeterm without the GUI, which rules it out for CI or for a remote box you only reach over SSH. Finally, the repository topics include ADHD, which tells you the design is opinionated toward visual, spatial working. If your workflow is keyboard-only and scripted, the canvas is a tax you pay for a feature you will not use.

Alternatives and how the approach differs

The closest conventional option is a tmux session with a tiling window manager or an editor-integrated terminal, where persistence comes from tmux and layout comes from splits. That keeps you in a shell, costs nothing, and has no Electron runtime, but it gives you no status badges, no context meter and no board. On the agent side, running several Claude Code sessions in separate tmux windows is the baseline nodeterm is trying to improve on; the difference is that nodeterm knows the agent's state through hooks and can surface a permission prompt as a node-level event, while tmux only knows the process is alive. A second comparison is a project tracker like a kanban tool wired to your terminal by hand. That gives you the board but not the live session behind each card, so the card and the work drift apart. nodeterm's claim is that the card is the session. That is a real architectural difference, and it is the reason to consider it over either alternative.

Maintenance, releases and the licence question

The release cadence visible in the material is fast: v0.3.3 on 2026-08-28, v0.3.4 on 2026-08-30, and v0.3.5 on 2026-09-10, all in the 0.3.x line. Three releases in under two weeks is a project still moving its surface area, so expect node behaviour and keyboard shortcuts to shift between versions. That has a direct cost: the README's own note that pre-upgrade terminals keep their old behaviour until you refresh the node means upgrades are not fully transparent, and you should refresh nodes deliberately rather than assume a restart picks everything up. The licence needs your attention before anything else. The repository metadata reports NOASSERTION, while the README badge states BUSL-1.1, the Business Source License. Those two signals do not agree, and I cannot resolve them from the supplied material. BUSL-1.1 is source-available rather than open source in the OSI sense, and it typically carries use restrictions and a change date. Read the LICENSE file in the repository and establish the terms for your own use case. This is not legal advice, and the discrepancy is exactly the kind of thing a legal review exists to settle.

Who should install it, and what to check first

nodeterm is aimed at a specific person: someone running multiple AI coding agents in parallel on macOS or Linux, who wants to see all of them at once and be told when one is waiting. If that is you, the tmux persistence plus hook-driven status is a combination that a plain terminal setup does not give you. If you need a headless tool, a Windows-first environment, or a licence you can build a product on without reading restrictions, this is the wrong project. Before committing, verify three things in order. First, open the LICENSE file and confirm the actual terms, since the metadata and the badge disagree. Second, check which tmux nodeterm will pick up on your machine, because a system tmux takes precedence over the bundled one and your existing configuration will apply. Third, install a 0.3.x release and test the restart path yourself: quit the app, reopen it, and confirm your agent sessions come back, because the README's upgrade caveat about unrefreshed nodes means this is the behaviour most likely to surprise you.

Editorial conclusion

Adopt nodeterm if you already run several Claude Code, Codex or Gemini sessions at once and keep losing them in tmux windows or editor tabs, and if you accept an Electron app and a source-available licence. Do not adopt it as a headless server tool or a general SSH client for a team, and do not assume the browser Server Edition is a drop-in replacement for the desktop app. Before installing, read the LICENSE file to establish the actual terms, since the repository metadata reports NOASSERTION while the README badge says BUSL-1.1, and check whether a tmux already on your PATH is the one nodeterm will use.

Official sources

1. eneskirca/nodeterm on GitHub
2. Issues
3. Project website
4. README
5. Releases