mmux vs workmux

What is workmux?

workmux, by Raine Virta, describes itself as "git worktrees + tmux windows for zero-friction parallel dev" [1][2]. One command, workmux add, creates a branch, a git worktree and a matching tmux window, copies or symlinks files such as .env and node_modules, runs post-create hooks and lays out your panes; workmux merge merges the branch and removes the worktree, the window and the local branch [1][4]. tmux is the main backend, with kitty, WezTerm and Zellij (experimental) as alternatives [1].

Its stated philosophy is that "tmux is the interface": instead of a separate app, agent status shows up as icons in tmux window names, in an optional sidebar pinned to every tmux window, and in a dashboard you open as a tmux popup [1][5][6][7]. Status comes from hooks that workmux setup installs for Claude Code, OpenCode, Codex, Copilot CLI, Pi, Oh My Pi, Gemini CLI, Grok and Antigravity CLI [5]. It also ships agent skills (/worktree, /coordinator, /merge) and optional sandboxing in containers or Lima VMs [8][9].

workmux is a Rust CLI under the MIT license, installed with a shell script, Homebrew, Cargo, mise or Nix. Version v0.1.276 was released on 2026-10-14 with binaries for macOS and Linux [2][3][10].

Where workmux is better

• Your terminal setup stays yours. workmux adds windows to the tmux session you already use, with your config, key bindings and status line, and it supports kitty, WezTerm and Zellij too [1]. mmux brings its own interface and keys and runs tmux out of sight, so a tuned tmux setup does not carry over.
• Sandboxed agents. workmux can run agents in Docker, Podman or Apple Container, or in a Lima VM, isolated from host secrets such as SSH keys and cloud credentials, and its docs spell out the threat model [9]. mmux has nothing comparable.
• More merge options. workmux merge can rebase, squash, merge into a branch other than main, or keep the worktree after merging, and the /merge skill lets the agent rebase and resolve conflicts itself [4][8]. mmux's M merges into the branch the worktree came from.
• Pull request and CI status. The workmux sidebar and dashboard can show a branch's pull request number and GitHub check status next to each agent [6][7].
• Hunk-level staging. The dashboard's patch mode stages individual hunks like git add -p [11]. The mmux git panel stages whole files and directories.
• More install paths. Prebuilt binaries for Intel Macs, plus Cargo, mise and Nix with a Home Manager guide [3][10]. mmux ships prebuilt binaries for Apple Silicon Macs and Linux only.
• Monorepo configs. workmux walks up from the current directory to the nearest .workmux.yaml, so each package in a monorepo can have its own config [12].

Where mmux is better

• No tmux to learn. Type mmux in a project and you get a sidebar of agents, terminals and processes, a main pane and a git panel, usable with keys or the mouse, and with a layout for phone-width terminals. The tmux session underneath is created and configured for you.
• Restore is automatic. Sessions survive closing the terminal or dropping SSH, and even after a quit, a crash or a restart-to-update, reopening the directory brings back your agents and terminals; Claude, Codex, Pi and Grok resume their conversation. workmux covers crashes with the workmux resurrect command, which you run yourself [13].
• Dev servers are first class. Processes get their own rows with start, stop, restart and an optional stop: teardown. Only one checkout of a repository runs a given process at a time: starting the dev server in a worktree stops it in the checkout that had it, so localhost:3000 is always the branch you last started it in.
• Status without hooks. mmux reads an agent's working and ready state from the terminal itself (progress escapes or the terminal title), so there is nothing to install per agent CLI.
• Notifications over SSH. A bell or an OSC 9/777 notification from any session becomes a native desktop notification, delivered as an escape sequence, so it reaches your local machine when mmux runs on a remote box.
• Worktrees tidy themselves up. A worktree with nothing running, a clean tree and every commit merged or pushed is removed after 30 idle minutes (configurable, or off); a branch with unmerged, unpushed work is never touched. We did not find an equivalent automatic cleanup in the workmux docs.
• Agents can drive the whole session. The control CLI lets an agent read a dev server's output (mmux read), wait for another agent (mmux wait), ask one a question and get the reply (mmux ask), or commit and merge a worktree (mmux commit --merge).

When to use which

Moving from workmux to mmux

1. Finish open workmux worktrees with workmux merge, or clean them up with workmux remove. mmux creates its own worktrees under ~/.mmux/worktrees/.
2. Install mmux and run mmux init in the project.
3. Carry over your .workmux.yaml: files you copied or symlinked go into worktrees.copy (files are copied, directories symlinked), a post_create install step becomes worktrees.setup, and dev server panes become processes. Agents go in ~/.mmux/config.yaml.
4. Run mmux and press w for a new worktree, or start one with an agent from the shell.

# ./mmux.yaml
name: my-project
processes:
  - name: Dev server
    cmd: npm
    args: ["run", "dev"]
worktrees:
  copy: [.env, .env.local, node_modules]
  setup: pnpm install

mmux worktree new fix-auth --prompt "fix the login bug"