Blog
How to run multiple coding agents in parallel on a Mac
Running four agents at once is easy. Stopping them from undoing each other's work, and knowing what any of them decided, is the part nobody warns you about.
· updated 31 August 2026
To run several AI coding agents in parallel on a Mac, give every agent its own git worktree so they never write to the same working tree, keep each agent's plan in a file outside its conversation so it survives context compaction, and never export a long-lived token into a shell an agent can read. Isolation and durability are the two problems, and both have to be solved outside the agent.
Start with isolation, not tooling
The single highest-value thing you can do costs nothing and requires no new app. Give each agent its own git worktree.
A worktree is a second working directory attached to the same repository, on its own branch. Two agents in two worktrees can run at full speed on the same project and physically cannot overwrite each other, because they are editing different files on disk. Without it, two agents in the same directory will eventually clobber each other's edits, and the failure is quiet: you find out at review time.
This used to be a manual git command and a cd. It is now built in almost everywhere: Claude Code takes a worktree flag and its desktop app gives every new session one automatically, and Cursor has a worktree command. Use whichever your agent ships, and fall back to one git command for the ones that ship nothing. Do this before you spend a single minute choosing a terminal.
What each agent now ships itself
Most of the isolation problem has been solved by the vendors in the last year, and the fastest setup is the one you already own. Check this list before installing anything.
- Claude Code: a worktree flag, and the desktop app puts every new session in its own worktree automatically. It also ships a sandbox.
- Cursor: version 3 added an Agents Window listing every running agent across your repos, local or cloud, with a worktree command for isolation and a practical ceiling around eight at once.
- Codex CLI: sandbox modes, a read-directory allowance, and parallel agents from the CLI.
- Copilot CLI, Gemini CLI, OpenCode and Zed: all runnable several at a time in ordinary tabs, with isolation still your job.
- Claude Squad and tmux: the featherweight answer, and the one that works over SSH on a box with no desktop.
What is left once the vendors have done their part
Two things, and neither is about count.
The first, and the one that actually costs money: isolation is about files, and the expensive failure is about credentials. This is documented rather than inferred. Anthropic's worktree page describes a .worktreeinclude file whose stated purpose is copying gitignored files such as .env into every worktree Claude Code creates, because a fresh checkout would not otherwise have them. Worktrees isolate edits on purpose and carry the credentials across on purpose. Two agents in separate worktrees still read the same environment, the same dotenv and the same shell history. A worktree stops them overwriting each other and does nothing about the token both of them can read. Every other failure on this page is recoverable — a bad edit is on a branch, a bad plan is rewritten. A key that has been read is rotated, and the copy that already reached a transcript or a git history is not coming back. Nothing any vendor shipped this year touches that, because it is not a coordination problem.
The second is smaller and more obvious: isolation per vendor is not coordination across vendors. Cursor's window shows you Cursor's agents. Claude Code's worktrees keep Claude Code's sessions apart. Run three vendors and you have three views of three subsets. A board that no vendor owns fixes it, and it is the sort of thing that should be free, which is how we ship ours.
Then decide how you will see them
Once each agent has its own directory, the next thing that breaks is your attention. Four tabs look identical, so you click through all of them to find the one that is blocked.
The common answers, in rough order of effort: name your tabs after the branch, which is crude and works; use tmux windows with meaningful names, which survives disconnects; or use a tool that groups sessions by the piece of work they belong to rather than by window position.
Whatever you choose, the test is the same. When one agent stops and waits for you, how long does it take you to notice, and how long to find it?
The problem nobody expects: the work does not survive
This is the one that costs the most time and gets the least attention. An agent spends twenty minutes reading your code and building a plan. Then the context window compacts, or you close the pane, or you quit for the day. The plan lived in the conversation, so it is gone. Tomorrow you explain the same project again.
It gets worse with several vendors. What Claude Code worked out is not readable by Codex, because each vendor keeps its own memory in its own format. You end up maintaining a separate brief per agent, or re-explaining constantly.
The free fix is a discipline, not a tool: before an agent starts, have it write the plan and its assumptions to a file in the repository. Any agent can read that file later, including a different vendor's. It is not elegant and it works.
The tooled fix is a durable task board that lives outside any conversation, that agents write to as they go and claim work from, and that carries no vendor field so any agent can pick up any task. That is what Forkbench builds, and it is worth saying plainly that this is our product, so check it rather than believe it.
Credentials: the part that becomes a real incident
The moment an agent has to push to GitHub, deploy, or call a paid API, it needs a secret. The default answers are a dotenv file or exporting the value into the shell, and both mean the agent, its logs, its scrollback and its context window can all read the raw value.
That is fine for a scoped, short-lived, low-privilege token, and it is how most people should start. It stops being fine for anything that touches production or costs money.
The two workable approaches: issue every agent its own scoped credential with the minimum permission it needs and a short expiry, so a leak is bounded and revocable; or use a tool that gives the value to one command's process rather than the shell, so the agent gets the result and never the secret. Forkbench's Vault does the second, with optional Touch ID per use. Either way, be clear about the limit: an agent you deliberately authorise to run a command could still print what it was handed. This is about accidental exposure, not a hostile agent.
If a key is already sitting in a .env file in one of your worktrees, that is a separate problem from parallelism and it deserves its own answer.
A checklist
If you take nothing else from this:
- One worktree per agent. Non-negotiable, free, and it prevents the worst failure.
- One plan file per piece of work, written before the agent starts, so nothing depends on a context window.
- Scoped, short-lived credentials, or a vault the agent never holds. Never a production token in a shell an agent reads.
- Something that tells you which agent is blocked, without clicking through every tab.
- A human accepting the work. An agent reporting it finished is a claim, not a verification.
Related: Stop coding agents reading your .env file
Frequently asked
How do I run multiple Cursor agents in parallel?
Cursor 3 ships an Agents Window that lists every agent currently running across your repos, local or cloud, and a worktree command that gives each one an isolated checkout. Around eight at once is the practical ceiling before merge conflicts start costing more than the parallelism gains. If you also run agents from other vendors, that window only shows you the Cursor ones, which is where a vendor-neutral board starts to earn its place.
Can I run agents from different vendors on the same project?
Yes, and it is the common case now that each vendor is good at different things. Give each agent its own git worktree so they never write the same files, and keep the plan somewhere none of them owns, because one vendor's memory is not readable by another. The part that does not solve itself is credentials: separate worktrees still share one environment.
How many coding agents can I run at once on a Mac?
The practical ceiling is usually your attention and your API rate limits, not the machine. Most people find three or four concurrent agents is where supervision starts to fail, which is the point at which isolation and a shared plan stop being optional.
Do I need git worktrees to run agents in parallel?
If they work on the same repository, yes, in practice. Without separate worktrees two agents edit the same files and silently undo each other. Separate repositories or separate clones work too, worktrees are just the cheapest version of the same isolation.
Can Claude Code and Codex work on the same task?
Not through their own memory, because each vendor stores context in its own format. They can share work through anything neutral that lives outside both conversations, which in the simplest case is a plan file committed to the repository, and in the tooled case is a shared task board that records no vendor on a task.