# Running several coding agents in parallel on Windows, without WSL or tmux > Source: > Published: 2026-08-21 01:50:06+00:00 I work on NestMux, so read this the way you would read anything written by someone with a stake in it. Everything I claim about other tools comes from the documentation each vendor publishes, and I link it so you can check instead of trusting me. Running one coding agent is easy. Running four is where it gets interesting, and where it breaks. Four agents on the same repository will overwrite each other's files. They will fight over the same working tree, the same branch, and, if you use more than one provider, the same credentials directory. The usual answer is one git worktree per agent, one terminal pane per worktree, and some way to see all of it at once. That last part is where Windows falls out. Claude Code has an agent teams feature that puts each agent in its own split pane. The backend for those splits is tmux, with iTerm2 as the alternative. Anthropic's own documentation says split-pane mode is not supported in Windows Terminal. tmux does not run natively on Windows. It runs under WSL, which means your agents run in a Linux filesystem, talking to a Windows checkout across a boundary that is slow for file watching and awkward for anything with a native toolchain. If you build with MSBuild, Unity, or Unreal, that boundary is not a detail you can ignore. So the feature exists. It just does not exist for you. This is the part I expected to be wrong when I started checking, and it was not. As of August 2026: Every one of these shipped in the last year, and every one of them treats Windows as a later problem. I do not think this is contempt. Mac is what the people building developer tools use, and you build for the machine on your desk. But the people who need this are not all on that machine. Game studios run Unity and Unreal on Windows. .NET shops run Windows. Regulated fintech and hospital IT run Windows because that is what their compliance posture was built around. Those are large teams with real budgets, and right now the answer they get is a waitlist. Nothing here requires a terminal multiplexer. It requires four things: **One worktree per agent.** `git worktree add ../feature-x feature-x` gives each agent its own checkout of the same repository sharing one object store. They can edit at the same time without touching each other's files, and you merge normally afterward. **An isolated HOME per agent.** This is the one people miss. Claude Code reads `~/.claude` , Codex reads `~/.codex` , Gemini CLI reads `~/.gemini` . Two agents under the same user account share the same config and, more to the point, the same authenticated session. If you want two Claude accounts running side by side, they need separate home directories. On Windows that means pointing `USERPROFILE` and `HOME` somewhere different per process, not just setting an env var and hoping. **A pane grid that is not a multiplexer.** tmux exists because terminals could not split themselves in 1980. A desktop application can just draw four terminals. Once you stop treating the multiplexer as a requirement, the Windows problem stops being a problem. **A way to review the output.** Four agents produce four diffs. Reading them one `git diff` at a time is where the time savings go to die. Here is the part where I am selling something, clearly marked. NestMux is a desktop application that runs Claude Code, Codex, Gemini CLI, Copilot and OpenCode side by side in a resizable pane grid. Each pane gets its own account, its own isolated HOME, and its own git worktree. There is a diff viewer for reviewing what the agents did, MCP server management, a broadcast mode to send one prompt to every pane, and voice input through a local Whisper model. It runs on Windows 10 and up, macOS 13 and up, and Linux. Same build, same features on all three. It is local-first with no telemetry: the code and the keys stay on the machine. Thirty-five seconds of it running: You should not need a product for this, and depending on your setup you might not. **Do it by hand.** Windows Terminal has panes. `wt.exe split-pane` will give you a grid, and you can drive each pane into a different worktree with a different `HOME` . It is fiddly to set up and you rebuild it every session, but it is free and it works today. **Use WSL and accept the boundary.** If your project is Node or Python and does not care where the filesystem lives, WSL plus tmux is a completely reasonable answer, and every Mac-first tool above becomes available to you through Sculptor. **Wait.** cmux has a Windows waitlist and Superset says it is coming. If you are not in a hurry, the market will probably solve this in a year. **Use one agent well.** A lot of the parallel-agents enthusiasm is people discovering that four mediocre agents produce four mediocre pull requests. One agent with good context often beats four without it. Parallel agents multiply output, and output is not the bottleneck for most teams. Review is. If you are already behind on reviewing what one agent writes, four will make that worse, not better. The setup pays off when the work is genuinely parallel: separate features, separate bugs, a migration split across independent files. It does not pay off when four agents are all guessing at the same underspecified ticket. If you run agents in parallel and you have found a different way through the Windows problem, I want to hear it, especially if it makes the case that this does not need a product at all.