NestMux runs five coding agents in isolated terminals with separate accounts and git worktrees

A developer has published a detailed write-up on dev.to describing NestMux, a desktop application that runs Claude Code, Codex, Gemini CLI, Copilot and OpenCode side by side in a grid of real terminals, with each pane isolated through its own account directory and its own git worktree.

How a pane works

According to the dev.to post, each cell in the grid is described by a plain data object holding an agent type, account name, account directory, command and repository path. The app contains no agent-specific logic: a pane spawns a shell with node-pty, redirects HOME to the pane's account directory, sets the working directory to its repository path, and types the agent command into it. Claude Code is simply a pane whose command is claude; an ordinary terminal is a pane with an empty command. Supporting a new agent CLI is a row in a list, which is why custom CLIs ship as a user-facing feature rather than a per-release addition.

Two of those settings carry the weight. Redirecting HOME means two panes can be signed into two different Claude accounts at once, since ~/.claude resolves differently in each. Pointing the working directory at a git worktree means several agents can edit the same repository without overwriting one another.

Broadcast sends keystrokes, not messages

Sending one prompt to every pane needs no protocol, the developer writes: the terminal emulator already exposes every keystroke, and broadcast mode just forwards input to all panes. Because it operates on raw input rather than structured messages, it works with anything that reads a terminal — TUI-based agents, a REPL, or an interactive rebase.

The cost is stated openly. Broadcast forwards everything, including Ctrl+C and arrow keys, and never checks whether a pane is ready, so a pane whose agent is still booting receives the prompt as input to whatever it happens to be showing. The developer frames the missing readiness detection as a deliberate position rather than an oversight, since adding it would mean parsing agent output, which any CLI update could break.

Resource attribution is the hard part

Per the post, the hardest feature is attributing CPU, memory and open ports to each pane, because the process NestMux spawns is a shell while the agent is its child, and a dev server the agent started may be a grandchild or fully reparented. The app resolves the process tree per pane on every polling cycle; on Windows this uses a machine-wide Win32_Process snapshot cached briefly and walked in memory. When the parent link is gone, it falls back to matching processes whose executable path or command line points inside a worktree, with a third pass reading each process's current directory through ntdll. The developer calls this a heuristic that misses elevated processes and those of other users, making the resource bar a useful signal rather than true accounting.

Diffs, sessions and what a restart loses

The built-in diff viewer shells out to git diff against a configurable base — HEAD by default, so it shows uncommitted work — and parses the unified diff in roughly a hundred lines with no library. Files over 10,000 lines are marked oversized and left unrendered so a regenerated lockfile cannot freeze the UI. The developer admits the default base is right for reviewing a just-finished agent but wrong when agents commit as they go, and that most users do not know they can change it, which is described as a UI failure.

Workspace layout persists in a session file written atomically — serialize, write to a temporary sibling, rename over the real file — after crashes mid-write used to leave truncated JSON. No terminal state is saved: scrollback lives in memory and dies with the PTY, so reopening the app respawns panes and re-runs the CLIs, losing the on-screen conversation, though most agents keep their own resumable histories.

Known gaps

The biggest gap, according to the post, is the absence of a unified log: no cross-pane timeline with timestamps and exit codes showing which agent touched which file and in what order. Only per-pane transcript exports exist. The developer attributes this directly to the design choice of not parsing agent output, and notes that filesystem watching per worktree would show what changed but not who changed it.

Why it matters

Running several coding agents in parallel is a workflow many teams are now adopting, and NestMux sketches a notably minimal architecture for it: isolation comes from the environment — separate HOMEs and separate worktrees — rather than from agent-specific integration. That keeps the app agnostic to CLI churn, at the price of observability capped at what the filesystem and process tables reveal. The write-up is a candid map of that trade-off for anyone building or evaluating multi-agent tooling. NestMux runs on Windows 10 and up, macOS 13 and up, and Linux from a single build, is local-first with no telemetry, and is free during launch at nestmux.com.