A parallel Claude Code agents workflow that holds up

Three parts, and the third is usually missing

Most parallel setups are one good idea repeated. Isolate the checkouts, and everything else is assumed to follow. It does not follow, and the two things that do not are the two that cost you a day rather than an hour.

A workflow that holds up has three parts, and they fail independently of each other.

• Isolation: every agent works somewhere no other agent is writing.
• Durability: the plan lives somewhere a closed pane, a compacted context and a change of vendor cannot take with them.
• Credentials: an agent does the work that needs a key without ever holding the key.

Comparison at a glance

Every tool here solves isolating the checkout; the credentials column is where most of them stop.

Part one: a worktree per agent

One repository will carry several checkouts at once, each on its own branch in its own directory. Point two agents at two of them and neither has a route to what the other is editing, so the silent overwrite that ruins an afternoon has nowhere to happen. This part is genuinely solved, and here is who solves it for you, checked against each vendor's own documentation as of September 2026.

• Claude Code: pass --worktree or -w with a name and it creates an isolated worktree and starts there. In the desktop app, select the worktree option when you start a session to give it its own.
• Conductor: a Mac app for running Claude Code, Codex and Cursor agents in parallel, which creates a separate git worktree and branch for each piece of work and keeps the agent's session attached to it.
• Claude Squad: a terminal app under AGPL-3.0 that uses tmux for the sessions and git worktrees for the isolation, across Claude Code, Codex, Gemini and other local agents including Aider.
• Warp: runs its own agent plus Claude Code, Codex and other CLI agents in separate tabs or panes, on macOS, Windows and Linux. Its guide tells you to create one worktree per agent yourself.
• tmux: no worktree feature and none needed. One git command per agent, sessions you can detach and reattach, ISC licensed and free.

Part two: a plan that outlives the conversation

An agent reads your code for twenty minutes and arrives at a plan. The plan lives in the conversation, so a compaction or a closed pane ends it. Multiply that by four agents and the cost is not the lost work, it is that you are the only place the four plans ever met.

Claude Code answers this inside its own family with agent teams, where one session acts as the lead, assigning tasks and synthesizing results while teammates work independently, each in its own context window, communicating with each other directly. It is experimental and off by default, enabled with the CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS environment variable, as of September 2026. Conductor takes a different route and gives each piece of work a shared context folder alongside its branch.

The question to ask of any of them is what happens when the coordinating session ends, because that is the difference between coordination and memory. If the answer is that the plan was in a conversation, you have bought a faster way to lose it.

The durable answer has a free form and it needs nothing installed. Make the opening move of any job be a committed file: the intended ordering, the assumptions underneath it, the approaches already discarded. Every agent afterwards can open that, whoever made it, and it is still there when the conversation that produced it is not.

The tooled version is a backlog and a set of notes that live outside every conversation, that agents claim from and write back to as they work, and that record no vendor on a task. Forkbench keeps exactly that, and it is ours, so hold it to the same test: open it after a compaction and see whether the plan is still readable.

Put a lead agent on top of that backlog and you have the durable version of agent teams: the lead plans on the board, helpers each take a task in a session of their own, and the plan is still there when every one of those sessions is gone. That is a squad, and there is a worked example of one here.

Part three: credentials the agents use without holding

Here the list gets short, and this is the part the roundups do not reach.

Of the tools above, none describes what happens to a credential, and two document the opposite on purpose. Anthropic's worktree page is explicit that a fresh checkout arrives without untracked files like .env, and offers .worktreeinclude as the supported way to have them placed in each new worktree. Conductor ships a files-to-copy setting for the same job, using .env.local as its own example. Both are correct engineering, because an agent cannot run the application without them. Both also mean the isolation you just built is designed to carry your secrets across it.

So after part one you have four agents that cannot overwrite each other and can all read the same tokens. That asymmetry is the whole point of this section. The first two parts fail into things you can put back: a branch you drop, a plan you write again. Revoke a credential and you have stopped it working, not stopped it existing, and the copy in a transcript or a log stays exactly where it landed.

The generic fix is real and you should do it today. Issue every agent a credential of its own, scoped to the one thing that agent is for and set to expire soon, so the worst case on the table is a narrow key with a short life rather than your account.

The other fix is to stop handing the value over. Forkbench files each piece of work as a Thread, and a Thread is the thing that carries the folders, the notes, the plan and the keys that one job needs. An agent working inside it runs the commands that require a key, and gets their answers back, without the value ever arriving in its prompt, its command line or its transcript.

The limit belongs in the same breath. Any agent in a terminal inherits your filesystem access, so a .env sitting in the project is as readable to it as it is to you. What moves is where the key lives, and moving it is one deliberate act on your part rather than something a tool performs on your behalf.

Which one to actually use

Forkbench is the only one here built to answer all three parts at once, which is the case for starting there. Here is what each alternative is good for if you want something narrower. Prices and flags are as of September 2026.

• The complete answer, for several vendors, work that has to outlive the pane, and keys you would rather no agent held: Forkbench.
• If you only ever run Claude Code and want no new app: its own worktree flag covers isolation and agent teams covers coordination while a lead session stays open, both for free, though neither survives past that session.
• If you want a Mac app watching several agents and do not mind paying for it: Conductor. Free tier, Pro at $50 a month, Teams at $60 per user, across Claude Code, Codex and Cursor, with a separate cloud product if you would rather the agents ran off your machine.
• On a remote box over SSH with no desktop: Claude Squad, or plain tmux if you would rather assemble it yourself. Both are free, neither needs a GUI, and tmux sessions survive the disconnect.
• If you want one tool's own agent across macOS, Windows and Linux: Warp, with the worktrees left to you.

The order to build it in

The useful move is not to pick one tool and hope it covers three problems. It is to take isolation from whatever you already run, because that part is free everywhere now, then decide deliberately where the plan lives, and then ask the credential question of whatever you chose.

Of the tools named on this page, only Forkbench answers that third question by keeping the key out of the agent's prompt and transcript, which matters because it is the only one of the three that leaves a mark you cannot undo. The step-by-step version of parts one and two, across Claude Code, Cursor, Codex and Copilot, is linked below.