dmux: a tmux multiplexer that gives every coding agent its own git worktree
A dev agent multiplexer for git worktrees and coding agents.
At a glance
- What is it?
- dmux wraps tmux panes around git worktrees so several coding agents can run in the same repository without stepping on each other. The idea is sound and the install is one npm command, but the tool assumes you already live in tmux and already have an agent CLI and an inference provider configured.
- Who is it for?
- Adopt dmux if you already run tmux, already have at least one supported agent CLI installed, and regularly want two or more agents editing the same repository at once. Skip it if you work mostly in a GUI editor, if you prefer one agent at a time, or if you cannot commit to tmux 3.0+, Node.js 18+ and Git 2.20+ on every machine you work from.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 30 days ago.
- What is it written in?
- Mainly HTML, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The collision problem dmux is built around
Run two coding agents against the same checkout and you get the failure everyone hits eventually: one agent rewrites a file the other is mid-edit on, or both stage overlapping changes and the second commit is nonsense. The usual workaround is to clone the repository twice or stash and swap branches by hand. dmux takes a different route. According to the README, it creates a tmux pane for each task, and every pane gets its own git worktree and branch, described as a full working copy so agents work in isolation. The audience is narrow and specific: developers who already drive coding agents from a terminal and want several of them running at once on one repository. If you run one agent at a time and wait for it, this tool adds a layer you will not use.
Panes, worktrees and where the state actually lives
The mechanism is a mapping between three things: a tmux pane, a git worktree on its own branch, and a running agent process. The README states that dmux creates the pane, the worktree, the branch and the agent launch in one step after you press n, type a prompt and pick one or more agents. Isolation comes from git, not from dmux: separate worktrees mean separate working directories, so two agents writing the same relative path are writing two different files on disk. The merge path is the reverse of that mapping. Pressing m opens a pane menu where Merge brings the branch back into your main branch, and the README describes this as auto-commit, merge and clean up in one step. Create GitHub PR is the other option there, which pushes the branch and files a pull request instead of merging locally. Nothing in the supplied material describes a server, a daemon or shared state beyond the git repository itself, which is the honest reading of the architecture: dmux is a coordinator over tools you already have.
Install and the first five minutes
Installation is a single global npm package. The README gives `npm install -g dmux`, then `cd /path/to/your/project` followed by `dmux` with no arguments. On first run the README says dmux can configure a primary inference provider and model plus an optional backup, discovering models from the provider where possible. It lists the supported routes: API-key providers, custom OpenAI-compatible endpoints, a Codex login backed by a ChatGPT subscription, and a Grok Build login backed by a SpaceXAI subscription. That flow can be reopened later with `s` then Inference Providers. The inference side is optional in the sense that the requirements section marks it as needed for AI naming, summaries and pane analysis, so a plain terminal pane should work without it. The hard requirements are not optional: tmux 3.0+, Node.js 18+, Git 2.20+, and at least one supported agent CLI. The README names Claude Code, Codex, OpenCode, Cline CLI, Gemini CLI, Qwen CLI, Amp CLI, pi CLI, Cursor CLI, Copilot CLI and Crush CLI.
Keyboard surface and what each key commits you to
dmux is a keyboard-driven tool with no visible mouse story in the README. The shortcuts table is short enough to memorise: n for a new pane with worktree and agent, t for a plain terminal pane, j or Enter to jump to a pane, m for the pane menu, f to browse files in the selected pane's worktree, x to close a pane, h to hide the selected pane, H to hide all others, p for a new pane in another project, P to show only the selected project's panes and then show all, s for settings, q to quit. Two of those deserve attention. Hiding a pane is not closing it, and the README says visibility controls let you hide panes or isolate one project and restore everything later without stopping work, so hidden agents keep running and keep consuming tokens. And f opens a built-in file browser that the README says can search files and preview code or diffs inside dmux, which matters because reviewing a diff before Merge is the only checkpoint between an agent's work and your main branch.
Branch naming, goal mode and the hooks you have to configure elsewhere
The default flow picks worktree and branch names automatically, with AI naming for branches, commit messages and active panes when an inference provider is configured. The README also documents two overrides: choosing a different base branch per pane, and supplying an explicit branch or worktree name, which it notes is useful for issue-tracker ticket naming. Multi-agent launches share the naming with agent-specific suffixes. Goal launches are a separate option, starting supported agents in goal mode from the initial prompt. Lifecycle hooks are listed as running scripts on worktree create, pre-merge, post-merge and more, but the README stops there and sends you to dmux.ai for configuration, so the exact hook names, their execution order and their environment variables are not verifiable from the repository description alone. Treat hook behaviour as something to confirm against the documentation site before you build a workflow on it.
Where dmux stops being the right tool
The isolation is per worktree, and that is also the ceiling. Two panes touching the same lockfile, the same generated migration, or the same shared config will still produce two versions of that file, and the merge step is where you find out. The README's Merge option is described as auto-commit, merge and clean up in one step, which means the tool is optimised for branches that merge cleanly; nothing in the supplied material describes a conflict-resolution interface. Disk and machine load are the second constraint. Each pane is a full working copy, so a repository with large assets or a heavy dependency tree multiplies that cost by the number of panes you keep open, and hidden panes keep running. The third constraint is the environment: tmux 3.0+, Node.js 18+, Git 2.20+ and a supported agent CLI are all mandatory, and the tool is a terminal UI, so anyone working primarily in an IDE panel is outside the intended surface. Finally, the repository's primary language is listed as HTML, which says nothing about runtime quality but does mean the code you would read to audit behaviour is not where you might expect it.
What you would use instead, and how the approaches differ
The obvious comparison is running agents in separate clones or separate checkouts by hand. That gives you the same isolation with no new dependency, and it costs you the coordination layer: no shared pane list, no per-pane menu that merges or opens a PR, no automatic branch and commit naming, and no durable terminal that restores a pane in its last observed directory. The README also claims dmux tracks a running Codex, Claude or other supported agent and resumes that conversation when the pane is recreated, which a manual clone workflow cannot do without you keeping notes. A second comparison is the agent CLIs themselves. Several of the supported agents ship their own session management and their own multi-task features, and if you have standardised on one of them, dmux is a layer on top rather than a replacement. The difference in approach is that dmux does not try to be the agent. It coordinates worktrees and terminals and delegates the actual coding to whatever CLI you already trust.
Maintenance, licensing and what the release cadence tells you
dmux ships under the MIT licence, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive position and it is the least complicated part of adopting the tool; it is not legal advice, and if you are redistributing a modified dmux inside a product, read the licence text rather than this summary. On maintenance, the repository is not archived, and the release list shows v5.10.0, then v5.11.0 and v5.11.1 within roughly a month of each other, with the most recent push and release on the same day. The version number sitting at 5.x after that cadence suggests a project that iterates on a stable interface rather than one still finding its shape. The upgrade cost is mostly on you: because dmux launches external agent CLIs and reads their state to resume conversations, a breaking change in any supported agent's output format is a dmux-side fix, and you inherit that dependency whether or not you changed anything. Pin the version you validate against and read the release notes between upgrades.
Editorial conclusion
Adopt dmux if you already run tmux, already have at least one supported agent CLI installed, and regularly want two or more agents editing the same repository at once. Skip it if you work mostly in a GUI editor, if you prefer one agent at a time, or if you cannot commit to tmux 3.0+, Node.js 18+ and Git 2.20+ on every machine you work from. Before trusting it with a real branch, verify three things on a throwaway repository: that your agent CLI is on the list of supported ones, that dmux can reach an inference provider or that you are willing to run without AI naming, and that the lifecycle hooks fire where you expect them to, since the README points to dmux.ai for the hook configuration rather than documenting it inline.
Community notes