Here is the shape most multi-agent workflows settle into: you open a project, you have three or four things that need doing, and you want each one running in its own lane. Maybe Claude Code is refactoring the auth module, Codex is writing tests for the billing API, and Aider is fixing a CSS regression someone reported this morning.
That sounds clean until you try to do it. Three agents in three terminal windows, all pointed at the same repo, all on different branches, all editing files that might overlap. You alt-tab between them. You lose track of which is which. One agent rebases on top of another and you spend twenty minutes untangling a merge conflict that should not have existed.
The fix is simple in concept and annoying in practice: give each agent its own copy of the codebase. Git has a feature for this called worktrees. An agent manager automates the worktree lifecycle and gives you one place to see everything. This post walks through the practical setup.
why agents need isolation
AI coding agents are not careful collaborators. They do not check what branch you are on before editing files. They do not notice that another agent is modifying the same function. If two agents write to the same file on the same branch, one of them will overwrite the other. This is not a bug in the agent. It is a property of how files and branches work.
The workaround people reach for first is separate branches. That helps with commits, but it does not help with the working directory. If both agents are checked out in the same folder, they are still fighting over the same files on disk. You need separate directories.
That is what git worktrees do. Each worktree is a full checkout of the repository in its own directory, on its own branch, sharing the same .git history. Agents in separate worktrees cannot interfere with each other. Their diffs are clean. Their commits are isolated. You review each one independently.
the manual way
You can set this up by hand. For each agent session:
git worktree add ../my-project-auth-refactor -b auth-refactor
cd ../my-project-auth-refactor
claude # or codex, aider, goose, etc.Do that three times, and you have three agents in three worktrees. Now open three terminals, navigate to the right directory in each, start the right agent in each, and keep track of which terminal is which.
Then, when each agent finishes, you need to review diffs, commit, push, and eventually clean up the worktree:
cd ../my-project
git worktree remove ../my-project-auth-refactorThis works. It also gets tedious fast. You forget to clean up worktrees. You misspell branch names. You lose track of which worktree is for which task. Environment files do not copy themselves. Port 3000 is already in use by another worktree's dev server. These are all solvable problems individually, but collectively they make the manual approach fragile.
the automated way
An agent manager handles the worktree lifecycle for you. In Pane, the workflow looks like this:
- → Open your repo in Pane. It detects the git root automatically.
- → Create a pane for each task. Each pane gets its own worktree, its own branch, its own terminal.
- → Pick an agent for each pane. Claude Code for the refactor, Codex for the tests, Aider for the bug fix. Any CLI agent works.
- → Switch between them with keyboard shortcuts. See the diff, terminal output, and git status for whichever pane is focused.
- → Review and ship each one independently. Commit, push, rebase, squash, or merge from the same interface.
The worktree creation, branch naming, environment file copying, and cleanup all happen automatically. When you close a pane, the worktree is removed. When you reopen Pane, your sessions are still there.
which agents can you run together?
Any combination that makes sense for your project. Each agent has strengths:
- → Claude Code is strong at large-scope refactors, understanding complex codebases, and multi-file changes.
- → Codex is fast at targeted edits, test generation, and applying well-defined changes.
- → Aider excels at iterative pair-programming sessions where you go back and forth.
- → OpenCode, Goose, and Cline each bring different model access and workflow opinions.
The point of running them in parallel is not that one agent is bad. It is that different tasks are better suited to different agents, and waiting for one to finish before starting the next wastes time you could be spending on review.
what to watch for
Running agents in parallel is powerful, but it surfaces real constraints:
- → Review load. Five agents producing 200 lines of changes each means 1,000 lines of diff to review. The bottleneck moves from "how fast can I produce code" to "how fast can I review it." Start with two or three parallel agents and add more as your review workflow improves.
- → Token costs. Running multiple agents burns through API usage or subscription limits faster. If you are on Claude Pro, multi-agent workflows can hit rate limits in 10-15 minutes. Check your plan's limits before scaling up.
- → Task decomposition. Agents work best on well-scoped tasks. "Refactor the entire backend" is harder to parallelize than "refactor the auth module," "add error handling to the payment service," and "write tests for the user API." Break work into pieces that do not touch the same files.
on windows
Most multi-agent tools are Mac-only or require tmux, which does not run natively on Windows. If you are on Windows or WSL, Pane is one of the few options that works out of the box. It ships a native Windows installer for both x64 and ARM64, handles WSL path translation for worktrees, and does not depend on any Unix toolchain.
See the complete Windows setup guide for a walkthrough from zero.
Install Pane with npx --yes runpane@latest or download from runpane.com. For more on how worktrees work under the hood, read Git Worktrees for AI Coding Agents.