So that two AI agents can share context in nodeterm, you draw a line between them. Each agent is a node on an infinite canvas, and drawing an edge from one to another gives the second a tool to read the transcript, summary, or recent terminal output of the first. nodeterm is a node-based terminal manager for macOS and Linux. Claude Code, Codex, Gemini, and opencode can be wired this way.
That feature is called Context Link, and it’s the reason to look at nodeterm. Running four agents in parallel isn’t hard: tmux has been doing it for years. The hard part is that each one starts blind. The agent doing the migration has no idea what the agent that just read the schema discovered, and you end up being the message bus, copying and pasting between panes. Context Link turns the canvas into that wiring.
What is nodeterm?
nodeterm is a node-based terminal manager, built with Electron, TypeScript, and React Flow. Instead of a tab bar you have a pan-and-zoom canvas where each node is a real terminal backed by PTY, an agent session, a Monaco editor, a git diff view, a chat panel, a sticky note, or a group frame.
An agent node doesn’t reimplement anything. According to the documentation, “an agent node is a terminal preset that launches a code agent’s CLI as a startup command, and then tracks what the agent is doing in the node’s header”. The four built-in ones launch claude, codex, gemini, and opencode respectively: whichever you already have in your PATH.
The status badge deserves a note for how it’s solved. nodeterm “does not parse the agent’s output to guess what it’s doing”. Each agent’s hook system publishes to a small loopback HTTP server inside nodeterm when a turn starts, a tool runs, work completes, or the agent goes back to waiting. That’s why the badges are accurate and not a heuristic over scraped stdout.
How does Context Link work?
You draw an edge between two built-in agent nodes: the same visual edge you already use to arrange the canvas. The documentation says it straight: “Context Link connects nodes on the canvas so one agent can see what another node knows”. The link can be unidirectional or bidirectional.
What the linked agent can retrieve are three things: the transcript (the full conversation history), a summary (a condensed version), and the recent terminal output (the stdout of that session).
The mechanism matters more than the feature list. It’s pull, not push: “reading is pull, not push; no agent is forced the other’s history”. Each agent receives a helper that it can invoke when it decides the other node is relevant — an invokable skill in Claude’s case, and instructions describing how to reach the link in the others. Nothing gets injected into anyone’s context window on your account, which is the difference between a useful link and a token bill.
How do you use Claude Code, Codex, and Gemini in the same project?
You open a folder as a project and add a node per agent. Each node runs the CLI you already have installed, with its own session and its own credentials; nodeterm doesn’t proxy or translate anything between them.
The pattern that makes this worth it is dividing by role instead of by task. A reader node that explores the repository and answers questions about the schema or architecture. A writer node that makes the changes. An edge from the second to the first, and the writer consults the reader when it needs to, instead of re-traversing the code itself.
That’s where the concrete advantage appears: the exploration work is paid once. Without the link, each new agent repeats the same repository reconnaissance and charges you for it in tokens.
If you’re interested in the problem of moving work between multiple agents, we’ve already covered two different approaches: OmniRoute, which aims at a universal runtime, and Cross-Code Organizer, which solves organization from a dashboard.
Which agents can be connected?
Only the four built-in ones: Claude Code, Codex, Gemini, and opencode. The documentation is explicit: “only built-in agent nodes can be linked as context sources. Custom agents and regular terminals can’t be read this way”.
So if you wrapped your own CLI as a custom agent node, or you want an agent to read what a build terminal has been printing, Context Link isn’t the way. It’s a real limit and it’s the first thing worth checking before designing a workflow around this.
The capability isn’t even across the four either. Claude Code has the broadest integration: subagent visualization, branching conversations, chat nodes, managed accounts, and permission modes. The other three have hook-based state detection, resumption after restart, and context linking, but not the rest.
What do subagents and branching conversations give you?
Two related context mechanics, both on Claude’s side.
When Claude launches subagents, “nodeterm shows each one as an ephemeral card connected by an edge to the parent agent node”, with the subagent’s type and task, whether it’s working or done, its duration, its tokens, and its tool usage count. Note: this is visualization of something Claude Code already does on its own. The documentation doesn’t describe a nodeterm-specific data exchange between parent and child, so don’t assume it exists.
Branching is different and does move context. Branching a Claude conversation “opens a new node that resumes the original conversation: the new node continues the thread as it was before the split”. You end up with two live sessions on the canvas that share everything up to the branch point and diverge from there. It’s the cheap way to try a second approach without losing the first.
How do you install nodeterm on Mac and Linux?
On macOS, download the .dmg from nodeterm.dev — the site detects whether you have Apple Silicon or Intel — open it, drag nodeterm to Applications, and launch it. No commands after that.
On Linux, the recommended way is the AppImage, because it auto-updates:
chmod +x nodeterm-*.AppImage
./nodeterm-*.AppImage
The .deb is the alternative and doesn’t auto-update:
sudo apt install ./nodeterm-*.deb
Then open a project: on the welcome screen choose Open folder and select your working directory. Right-click on an empty spot on the canvas, or press the + in the bottom dock, and choose terminal — or a Claude, Codex, Gemini, or opencode node, which are added exactly the same way. ⌘K opens the command palette to create nodes, jump to one by title or label, and switch projects.
Why do you need tmux?
Because without it the persistence promise doesn’t hold. The documentation is direct: session continuity depends on tmux and “without it, a terminal is a plain shell that ends when its node closes”.
With tmux in your PATH, terminals run inside tmux sessions that survive the application: you close nodeterm, restart the machine, reopen the project and the long-running work is still there. It’s the most useful property of the tool and also the one that fails silently if you skipped the dependency. Run which tmux before blaming the app.
Does nodeterm work on Windows?
No. The documentation lists macOS (Apple Silicon or Intel) and Linux (x64) only, and there’s no Windows build. The alternative it points to is the Server Edition: run nodeterm headless on a Linux machine and reach the canvas from the browser. WSL doesn’t appear mentioned as a supported path.
Is nodeterm open source?
Not in the OSI sense. The license is BUSL-1.1, the Business Source License. The code is public on GitHub and you can read it, modify it, and use it in production; what you can’t do is offer it as a competing service. Each release becomes MIT four years after publication.
For most readers that distinction is academic: you install it and use it at work today. If you need to pass dependencies through legal, or you’re deciding whether to build on top of it, it’s not academic at all — and the “open source terminal manager” framing you’ll see around is incorrect.
One detail to check before downloading: at the time of publishing this note, in September 2026, nodeterm.dev announces v0.3.4 with an “early access” label, while the most recent release-tagged version on GitHub is v0.2.9, from July 14, 2026. The download and the repository aren’t on the same version, so read the GitHub tags as lagging behind and not as the current state of the product.
Is it worth installing?
If you run one agent at a time, no. tmux and your terminal already do this, and the canvas is a window manager you didn’t ask for.
If you run three or four against the same repository and you’re the one passing findings from one to the other, Context Link is exactly what you were missing, and no one else is shipping this form of the problem. Just size expectations correctly: early access, small project, restrictive license, and a link that only reaches the four integrated agents. Evaluate it as a tool, not as infrastructure.