dmux: parallel coding agents in tmux panes and git worktrees

The problem dmux solves: one repository, several agents, no branch collisions

Running two coding agents against the same checkout produces the failure everyone hits eventually. Both write to the same files, both stage the same index, and neither can be reviewed on its own. dmux's answer is isolation by construction. Each task gets a tmux pane, and each pane gets its own git worktree and branch, so the README's claim that agents work in "complete isolation" follows from git rather than from any locking layer dmux adds.

The audience is narrow and specific. You need to be comfortable in tmux already, because dmux is a control surface over tmux panes rather than a replacement for them. You need at least one supported agent CLI installed, from a list that includes Claude Code, Codex, OpenCode, Cline CLI, Gemini CLI, Qwen CLI, Amp CLI, pi CLI, Cursor CLI, Copilot CLI and Crush CLI. And you need a repository where parallel branches make sense. If your work is a single sequential change, the worktree machinery is overhead with no payoff.

How dmux maps tasks onto panes, worktrees and branches

The data flow starts with a prompt. You press n for a new pane, type the prompt, and pick one or more agents, or none at all for a plain terminal. dmux then creates the worktree, picks the branch name, and launches the selected agent CLIs inside the pane. Multi-select launches are supported, so one prompt can fan out to several agents at once; the README states that multi-agent launches use shared naming with agent-specific suffixes, which is how you tell the resulting branches apart.

Branch naming is not fixed. The default flow lets dmux choose the worktree and branch names automatically, and the README describes two overrides: choosing a different base branch per pane, and supplying an explicit branch or worktree name, which it suggests is useful for issue-tracker ticket naming. That second override matters more than it looks. Automatic names are convenient until you need to correlate a branch with a ticket, and the escape hatch is the difference between a demo and a workflow.

When a task finishes, the pane menu opened with m offers Merge, which the README describes as auto-commit, merge and cleanup in one step, or Create GitHub PR, which pushes the branch and files a pull request. There is also a built-in file browser on f that inspects a pane's worktree, searches files and previews code or diffs without leaving dmux. The repository layout backs this up: src/, frontend/, native/ and a docs/ directory sit alongside a pnpm workspace, and package.json declares the package as a tmux pane manager with AI agent integration.

Installing dmux and creating your first worktree pane

dmux ships as a global npm package. The README gives a single install command, and package.json sets the engine requirement at Node.js 18 or later.

npm install -g dmux

With the binary on your path, change into the repository you want to work on and start dmux with no arguments. It runs against the current directory, so the project you are standing in is the project it manages.

cd /path/to/your/project
dmux

Inside the interface, press n to create a new pane. dmux asks for a prompt, then asks which agents to launch; you can pick one, several, or none for a plain terminal. After that it creates the worktree and branch and starts the agent. The keyboard reference in the README lists the rest: t for a terminal pane, j or Enter to jump to a pane, m for the pane menu, f for the file browser, x to close, h and H for visibility, p and P for multi-project work, s for settings, q to quit.

On first run dmux can configure a primary inference provider and model, with an optional backup. The README says it discovers models from the provider when possible and supports API-key providers, custom OpenAI-compatible endpoints, a Codex login backed by a ChatGPT subscription, or a Grok Build login backed by a SpaceXAI subscription. You can reopen that flow later with s and then Inference Providers. The provider is optional for basic use; the README lists it as needed for AI naming, summaries and pane analysis.

Where dmux gets in the way

The tmux dependency is not incidental. dmux requires tmux 3.0+, Node.js 18+ and Git 2.20+, and it is a manager of tmux panes rather than an abstraction over them. If you work in a GUI editor, or on a platform where your tmux setup is unusual, you are adopting two tools at once. The README does not document a fallback mode that runs without tmux.

The merge step deserves scrutiny. The README describes smart merging as auto-commit, merge and cleanup in one step, and it does not document rollback. If an agent's work is half-finished and you trigger Merge, the documentation gives no described undo path; you are relying on git reflog and your own judgement. For a tool whose whole premise is unattended parallel work, that is the sharpest edge in the design, and it is worth treating the pane menu as a deliberate action rather than a reflex.

Provider configuration is a second soft spot. AI naming, summaries and pane analysis all depend on an inference provider, and the README lists that provider as optional only in the sense that dmux runs without it. The features it powers are the ones that make a wall of panes legible, so a user who skips configuration gets a less readable interface than the screenshots suggest.

Finally, consider the shape of your work. dmux optimises for many independent tasks against one repository. A refactor that touches every file, or a change that must land as one commit, gains nothing from being split across worktrees and loses the ability to review it as a whole.

dmux compared with running agents by hand in tmux and git worktrees

The honest alternative is the manual version: create a worktree with git worktree add, open a tmux window, cd into it, and start your agent CLI. That is exactly what dmux automates, and the automation is not trivial. You get branch naming, agent launching, a pane menu with merge and PR actions, a file browser, lifecycle hooks on worktree create, pre-merge and post-merge, plus durable terminals that restore in their last observed directory and, according to the README, resume the tracked conversation when Codex, Claude or another supported agent was running in that pane.

What you keep by doing it by hand is transparency. Every step is a command you typed, and nothing happens implicitly. What you lose is the bookkeeping: remembering which pane maps to which branch, which agent is still running, and which worktrees are stale. dmux's value is concentrated in that bookkeeping and in the merge and PR actions, not in the isolation itself, which git already provides.

A second comparison point is the broader family of terminal session managers that the search results around this project surface. Those tools generally manage sessions or panes without the git worktree and coding-agent layer. dmux's distinguishing choice is that it binds a pane to a branch and to an agent CLI, and it treats the merge back to the main branch as a first-class action. If you do not want an agent CLI in the loop, that binding is dead weight.

Maintenance, release cadence and the MIT licence

The repository is not archived, and the last push was on 2026-08-16. Releases in the visible history are v5.10.0 on 2026-07-09, v5.11.0 on 2026-08-15 and v5.11.1 on 2026-08-16, so the most recent version is a patch on top of a minor released the day before. That is a normal cadence for a tool at this stage, and it also means the surface you adopt is moving. The package version in package.json is 5.11.1, matching the latest release.

dmux is MIT licensed, which places few restrictions on use and redistribution; the LICENSE file sits at the repository root. The practical consequence for an engineering team is that there is no commercial support contract attached, and no vendor to escalate to. If you need a support agreement, this is not the project for that.

Upgrade cost is the part worth planning. dmux shells out to agent CLIs that change on their own schedules, and it depends on tmux and git versions that vary by machine. A dmux upgrade can therefore interact with a change in an agent CLI you did not make. Pinning the global package version and reading the release notes before moving is the cheap insurance. The repository also carries a pnpm workspace and a build pipeline in package.json, but that matters only if you are building from source rather than installing the published package.

Editorial conclusion

dmux fits engineers who already live in tmux and want several agent CLIs working on one repository without branch collisions. It is the wrong tool if you do not use tmux, if your work is a single sequential task, or if you want a hosted service rather than a local terminal multiplexer. Before adopting it, verify that your machine has tmux 3.0+, Node.js 18+ and Git 2.20+, that at least one supported agent CLI is installed, and that you have an inference provider key or a Codex or Grok Build login if you want the AI naming and pane analysis features. Then read the hooks documentation at dmux.ai before you wire anything into worktree create or pre-merge.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. standardagents/dmux on GitHub