wmux: a workspace multiplexer for running Claude Code, Codex and Gemini side by side

What wmux is for, and who it is actually aimed at

Running one coding agent in one terminal is easy. Running four of them against the same repository is not, because they collide: two agents editing the same file, three shells whose scrollback you cannot reconstruct, and no clean way to take one good change and reject the rest. wmux positions itself as a workspace multiplexer rather than a terminal multiplexer. The README draws the line explicitly: tmux splits a terminal, while wmux multiplexes whole workspaces, meaning terminals, agents, git worktrees, a browser, and the coordination channels between them, all owned by a daemon.

The audience is narrow and specific. You need to already be a user of Claude Code, OpenAI Codex or Gemini as command-line agents, on Windows 10/11 or Apple Silicon macOS, and you need enough parallel work to justify a GUI. The README states the project has been building in the open since March 2026, and the repository's last push was on 2026-09-14, with v3.55.0 released the same day. That cadence matters if you are deciding whether to depend on it: this is a fast-moving codebase, not a frozen tool.

What it is not: a hosted service, a Linux application, or a replacement for your editor. The workspace diff is described as read-only, with the README noting there is no IDE creep. That is a deliberate boundary, and it tells you wmux expects you to keep reviewing code where you already review it.

Panes, worktrees and the daemon that outlives the window

The architecture visible in the repository is a set of layers. An Electron app (forge.config.ts, vite.main.config.ts, vite.preload.config.ts, vite.renderer.config.ts) provides the window. A separate daemon is compiled from tsconfig.daemon.json and bundled to dist/daemon-bundle/index.js. A CLI is bundled to dist/cli-bundle/index.js and exposed as the `wmux` binary through package.json's bin field. An MCP server builds from tsconfig.mcp.json and runs via `npm run mcp`. The README describes the daemon as the owner of the workspaces, which is what lets sessions come back after a quit, a crash, or a full OS reboot.

Each pane is its own PTY. The README's hero description says four panes in one window, each pane its own PTY, with a roster and an orchestrator in a side dock. The orchestrator is the part worth understanding: rather than a chat window that only talks to you, it picks an idle pane, hands it a task, and relays the answer back. That is agent-to-agent delegation inside the same window, not a separate chat product.

The fan-out mechanism is git worktrees. One prompt goes out to N isolated worktrees, so each agent works on its own checkout and cannot stomp on another's files. Harvesting is where the design gets opinionated. Adoption is described as atomic: you tick the hunks you want, and they land as a single all-or-nothing `git apply`. Your tree takes the whole selection or stays untouched. That is a real constraint, not a marketing line. If two selected hunks conflict, you do not get a partial merge to clean up; you get nothing applied and a re-selection to make.

Channels are the third coordination primitive. They are described as Slack-style rooms that agents read, post to, and get @-mentioned into, with a server-verified sender, and they survive a reboot. Loops are the fourth: point the orchestrator at an objective, optionally with per-iteration steps drawn from your `.claude` skills and a done-when checklist, and it keeps working, woken by agent events.

Installing wmux and running your first fan-out

On Windows the README recommends a package manager, because the Setup.exe installer is signed with a SignPath test certificate and still triggers a SmartScreen unknown-publisher prompt. winget and choco skip it. One command does the install:

winget install openwong2kim.wmux

If you prefer Chocolatey, the README lists `choco install wmux` as the alternative. For an offline machine, download Setup.exe from the releases page and accept the SmartScreen prompt.

On macOS the path is different. There is no package manager step in the README: download the .dmg from the releases page and drag wmux to Applications. The build is Developer ID signed, notarized and stapled, so it opens without a Gatekeeper detour. On first launch the `wmux` CLI installs itself onto your PATH, which is what makes the CLI usable from an existing terminal afterwards.

Both platforms self-update. The README states wmux checks for a new release every 30 minutes and verifies the download against a published SHA-256 before installing, for Windows x64 and macOS arm64.

For the first real use, the sequence implied by the docs is: open a repository as a workspace, split panes, and start an agent in each. The fan-out flow is the one to try first because it exercises the whole pipeline. Send one prompt to N worktrees, let the agents finish, then open the Git dock's diff for the active pane and select hunks. Adoption applies them as one operation. Expect either a clean apply or no change at all.

If you want approvals on your phone, the iOS app is a companion to the daemon, not a standalone client. Start the web bridge:

wmux web

The README says to run it over HTTPS, that the titlebar web popover has a one-click Tailscale option, and that scanning the QR code it shows pairs the phone. After pairing, an agent's question or approval prompt arrives as a push notification; Face ID plus Approve or Deny advances the pane on the desktop.

Where wmux gets in your way

The atomic adoption model is the sharpest trade-off in the product. All-or-nothing is excellent when you want confidence that nothing half-applied landed in your tree. It is worse than a normal patch workflow when your selection is large and one hunk is stale, because the failure is total. You re-tick and try again. The README does not document a partial-apply fallback or a dry-run preview of the combined selection, so plan on treating adoption as a single decision rather than an incremental one.

Platform coverage is the second limit. The README names Windows 10/11 and Apple Silicon macOS. There is no Linux build documented, and no Intel Mac build documented either; the release assets described are Windows x64 and macOS arm64. If your team is on Linux, wmux is the wrong tool and the repository does not pretend otherwise.

The Windows signing situation is a genuine friction point that the project itself flags. The installer uses a SignPath test certificate, so SmartScreen warns. The README's workaround is to install through winget or choco. On a managed corporate Windows fleet where package managers are blocked, that leaves you clicking through a warning, which some security teams will not accept.

The iOS app adds a dependency you may not want. It is a companion to the daemon, requires `wmux web` over HTTPS, and the README suggests Tailscale for the network path. That is an extra service in the loop between your laptop and your phone. If your threat model does not include exposing a daemon over a tunnel, skip the phone approvals and keep everything local.

Finally, the repository is dense. Top-level entries include ARCHITECTURE.md, DESIGN.md, decisions.md, handoff.md, progress.md and TODOS.md alongside core/, relay/, rig/ and integrations/. That is a lot of surface for a project at version 3.55.0, and it means the documentation is spread across files rather than concentrated in the README.

How wmux differs from tmux and from single-agent CLIs

The obvious comparison is tmux, and the README makes it directly: tmux splits a terminal, wmux multiplexes workspaces. The practical difference is what survives and what is coordinated. A tmux session persists processes, but it has no concept of a git worktree per pane, no hunk adoption step, no agent roster, and no approval channel to a phone. If you already live in tmux and your agents are well behaved, wmux adds a GUI, an Electron runtime, a daemon and an iOS dependency to solve problems you may not have.

Against running a single agent CLI in one terminal per project, the difference is isolation and harvest. One terminal means one working tree, so two agents editing concurrently is a merge problem you resolve by hand. wmux's worktree fan-out gives each agent its own checkout, and the atomic adoption step is the mechanism for pulling results back. That is a workflow, not just a window manager.

The comparison the README itself invites is with IDE-integrated agent panels. wmux explicitly keeps the diff read-only and outside an editor. If your habit is to review changes inline in VS Code with an agent panel attached, wmux will feel like it is asking you to switch tools mid-task. The repository's answer is the Git dock and the workspace diff, which show staged, unstaged and untracked changes against HEAD, and the ability to ask the orchestrator about a specific hunk with the repo, file and code fenced into the message.

Maintenance, licensing and what an upgrade costs you

The repository is not archived, and the last push was on 2026-09-14. Releases v3.53.0, v3.54.0 and v3.55.0 landed on 2026-09-12, 2026-09-13 and 2026-09-14 respectively, which is a daily cadence across those three days. For a tool you would put in front of your daily work, that is a positive signal about responsiveness and a warning about churn: minor versions are arriving often enough that pinning matters. The app self-updates every 30 minutes by default, so if you want to control the version, that behaviour is the thing to override first.

Licensing is MIT, which is permissive and imposes few obligations beyond retaining the notice. The repository also carries THIRD_PARTY_NOTICES and a license-allowlist.json with a `npm run licenses` script (scripts/check-licenses.mjs) and a `npm run notices` script (scripts/generate-notices.mjs). That tooling suggests the project tracks its dependency licences deliberately. It does not tell you whether the combination of Electron, node-pty and the rest fits your organisation's policy; only your own review of THIRD_PARTY_NOTICES will. Nothing here is legal advice.

The upgrade cost is mostly operational. Because the daemon owns the workspaces and sessions are designed to survive a reboot, an upgrade is not just replacing a binary: it is replacing the thing holding your running agent conversations. The README does not document rollback, and it does not document what happens to in-flight agent sessions during an in-place update. If you run long agent loops, test an upgrade on a scratch workspace before letting it touch the one you care about.

Editorial conclusion

Adopt wmux if you already run more than one coding agent and want them in one window with worktree isolation, hunk-level adoption and approval prompts that reach your phone; the winget and Chocolatey package paths plus the notarized macOS build make the install low-risk to try. Do not adopt it if you need Linux, or if you want a plain terminal multiplexer with no Electron layer, no daemon and no iOS companion. Before trusting it with a real repository, verify three things yourself: that `git apply` behaves the way you expect when a selection conflicts, that the daemon restart genuinely restores the agent conversations you care about, and that the MIT licence plus THIRD_PARTY_NOTICES cover every dependency your organisation cares about. The project's own docs are the only place those answers exist today.

Frequently asked questions

Official sources

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