How to run multiple Claude Code agents in parallel

Three ways to run multiple Claude Code agents

Starting four Claude Code sessions is the easy part. The trouble arrives a minute later, when you become the wiring between them. You split the job in your head, paste what one tab found into another, and click through all of them to see who has finished and who has been waiting on a yes for twenty minutes. Past three agents you are not coding any more. You are dispatching.

So the useful question is not how to start several agents. It is who coordinates them, and there are three answers.

• You do. Several terminals, one claude in each, and a list in your head. Fine for two. By four, you are the bottleneck.
• Claude does, inside one session. Subagents let a session delegate to workers that each start with a fresh, isolated context. Agent Teams, an experimental feature that is off by default, puts a lead session and teammate sessions on a shared task list (how the two compare). Both are Claude only, and both end with the session that started them.
• A lead agent does, out in the open. That is a squad in Forkbench: one agent plans and delegates, the others each get a task and a session of their own, and the plan lives on a board that is still there tomorrow.

Comparison at a glance

The same job, three ways. Read the last column first: it is what you still have when the session that started everything is gone.

How a Forkbench squad works

Easier to show than to define. Say the job is adding team invitations to an app. You write that on the Thread's board and start Claude Code as the lead. It reads the code and breaks the job down: the database migration, the invitation email, the page where someone accepts, the tests. Then it calls in a helper for each, and a row of chips on the lead's tab shows four agents at work.

A few minutes in, one of them stops and asks: do invitations expire? You answer in a sentence, at your desk or from your phone, and it carries on. When you come back from a coffee, three tasks are waiting for you, each with the notes its helper left about what it changed and why. You read the diffs, accept two and send one back.

Look at what you did not do. You never pasted context from one tab to another. You never asked who was working on what. You made one decision and reviewed three pieces of work, which is the part of the job that needed you.

Setting it up takes about a minute.

• Write the goal on the Thread's board and switch Squad on for that Thread.
• Tell it which agents it may call. A helper is a name and the command that starts it, so anything you already run in a terminal qualifies: Claude Code, Codex, Cursor CLI, Aider, OpenCode. A Claude lead handing the tests to Codex is a normal squad, and most of what one learned carries over to the other.
• Decide how you want to see them. A helper that speaks the Agent Client Protocol runs in the background, with a live feed of what it is doing and a card when it wants permission. Any other agent runs in a terminal of its own.
• Start one agent and tell it to lead. It plans on the board and calls the helpers it needs. If it wants an agent you have not added, it can suggest one, and nothing happens until you say yes.
• Review what comes back. A helper can report a task finished, and only your acceptance makes it done.

Why a fresh session per task matters

Think about how you brief a contractor. You hand over the task and the two documents that matter. You do not hand over six hours of meeting recordings and ask them to find the relevant part. A long agent session is the meeting recordings.

This is measured, not folklore. Researchers call it lost in the middle: across several model families, a model answers best when the information it needs sits at the start or the end of its context, worse when it is buried in the middle, and worse again as the context grows. It is why a session that was sharp at nine is vague by noon, well before the context window fills and compacts.

A helper that starts clean has only its task, the notes that go with it and the files it touches, so it works the way the first hour of a session works, every time. The lead stays sharp for the opposite reason: it never fills up with code, because it is not writing any. Anthropic built its own multi-agent research system on the same shape, a lead directing subagents, and Claude Code gives each subagent a fresh context window for the same reason.

It is also why a squad can take on unrelated things at once. A migration, a flaky test and a docs fix can all move this afternoon, because no two of them share a head.

The price is tokens, and it is worth knowing before you start: Anthropic measured multi-agent systems at about fifteen times the tokens of a chat. A squad earns that on work that splits into independent pieces. For one tightly coupled change, one agent is still the right call. And if four agents run you into a usage limit, queue the next prompt for when it resets instead of starting cold.

Keep them off each other's files with git worktrees

A lead agent settles who does what. It does not stop two helpers saving over the same file, and that failure is quiet: you find out at review time.

The fix is a git worktree per agent, a second working directory on its own branch, so two agents cannot physically touch the same file. Claude Code has a flag for it, Cursor has a command, and in Forkbench it is one click from the git panel. The git worktrees explainer has the detail, and the terminal roundup covers what else changes once you run more than one session.

What each agent now ships itself

Most of the isolation problem has been solved by the vendors in the last year, so it is worth knowing what is already covered. Here is what each one ships.

• Claude Code: a worktree flag, and the desktop app gives a new session its own worktree when you pick the worktree option. 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. Cursor publishes no recommended number of agents at once.
• Codex CLI: sandbox modes, a read-directory allowance, and parallel agents from the CLI.
• Copilot CLI, Antigravity 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 ours records nothing about which agent wrote a task, so any of the three can claim any of it, with no cap on how many agents work one board.

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. Forkbench builds that board into every Thread, and it is ours, worth weighing against the plain file above since both cost nothing.

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.

Going deeper on squads

Each of these takes one question this page only touches and answers it properly.

• The orchestrator-worker pattern: what a lead and its workers each do, and where the pattern breaks.
• Which model should lead and which should do the work: a decision rule, and how Claude Code resolves a subagent's model.
• Running Claude Code and Codex together: what has to live outside both for a mixed squad to work.
• Context rot: why a long session gets worse, and the fixes in order of cost.
• Is a multi-agent squad worth the tokens: the measured multipliers and a checklist before you start one.
• How many subagents can really run at once: the documented ceiling, and the real one.
• When helpers edit the same file: the two kinds of collision and the setup that stops both.
• When a subagent gets stuck: a triage list for a lead that is waiting on nothing.
• When an agent games its own tests: the documented tactics, and why the acceptance step exists.
• Human approval across a hierarchy of agents: approving before an action versus accepting after the work.

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.