Run Claude Code agents in parallel without collisions
Starting four agents at once takes a second. Keeping them out of each other's working directory is the part that decides whether you get four results or one unusable diff.
Parallel agents are not blocked by tokens or by your machine. They are blocked by the working directory: two agents editing one checkout will overwrite each other's uncommitted work, and neither will notice. Give each writer its own directory — a detached worktree is the cheapest way — or accept that you are serializing them and approve their writes one at a time.
The bottleneck is the filesystem, not the model.
The appeal of running several coding agents at once is obvious: four independent tasks, four times the throughput, one review pass at the end. The failure mode is just as obvious in hindsight and almost never anticipated.
Two agents pointed at the same repository do not coordinate. They both read the file, both plan against what they read, and both write. The second write lands on top of the first, in an uncommitted working tree with no history to recover from. The agents report success — from where each one is standing, it succeeded — and the damage surfaces later, in a diff nobody can explain.
This is why "how many agents can I run?" is the wrong opening question. The number of panes is free. The number of independent writers is what you are actually provisioning, and that is a filesystem decision.
If two tasks share a working directory, you do not have two agents. You have one agent taking turns, plus a race condition.
Three honest ways to give a writer its own ground.
| Approach | What it costs | When it is the right call |
|---|---|---|
| Separate clones | Full disk copy per agent, and remote fetches to set each one up. | Rarely — the isolation is real but the setup is slow and the copies drift. |
| Detached worktrees | One checkout per tree, sharing the object store; cheap and local. | The default for concurrent writers on one repository. |
| Read-only tasks | Nothing — no writer, no conflict. | Research, review, and scouting work that only needs to read. |
Worktrees are the pragmatic answer because they are local, quick to create, and disposable in principle. The caveat is that "disposable in principle" is how people lose work: a tool that cleans up its own worktrees will eventually delete the only copy of something an agent wrote and you had not yet looked at.
The safer contract is that a tool may create isolation and must never destroy it. If a worktree comes back dirty, that dirt is the output. It should be held for a human, not tidied away.
Four streams need four sets of controls, not one status line.
Parallelism moves the cost from waiting to watching. A board that shows four transcripts but one shared control strip is worse than four terminals, because it hides which pane is asking for something. Each running task needs its own:
- Stream and transcript, so you can read what it is actually doing rather than a spinner.
- Status and cost, because a task that is quietly burning context is the one you want to stop first.
- Permission prompts, answered against that task's own tool call and input — never batched across panes.
- Stop control and follow-up composer, so steering one task does not disturb the other three.
- Focus and collapse, because four live streams at full size is not a readable screen.
And one board-level affordance that matters more than the rest: a cue that jumps you to the next task awaiting a decision. Without it, watching four agents becomes a polling loop, and the throughput you bought is spent scanning.
Five rules that survive contact with a real run.
- Default to asking before tools.A parallel task is exactly the situation where you are not reading every line. Starting in the safe approval mode is not friction; it is the only thing standing between four agents and four unreviewed shell commands.
- Make overlap visible, not fatal.Sometimes two tasks in one directory is what you want. The interface should keep the warning on screen and make you approve overlapping writes one at a time, rather than either blocking the run or letting it race silently.
- Never clean up on the agent's behalf.No automatic removal, reset, or clean of a worktree. Uncommitted agent output may be the only copy in existence.
- Cap the concurrency deliberately.The limit is human, not technical: past about four live streams, review quality falls faster than throughput rises.
- Keep each task's history native.Every pane should leave an ordinary provider transcript behind, so a parallel run is reviewable — and resumable — after the board is closed.
What Crowsnest ships today.
From inside a live conversation, Run parallel starts up to four independent sessions on the current provider and lays them out as a responsive task board. Every pane streams at once and keeps its own status, cost, permission prompts, Stop control, follow-up composer, focus and collapse state, and native transcript. A board-level cue jumps to the next task awaiting a decision, and tasks always start in the safe “ask before tools” mode.
When tasks share a working directory the board keeps a warning visible and you approve overlapping writes one at a time. You can point a task at an existing worktree or directory for real isolation, and Crew can provision detached local worktrees under application-owned storage — up to eight per repository pool. Crowsnest never removes, resets, or cleans a worktree: a dirty result is held for you, because it may be the only copy of an agent's work.
The parallel board is part of Pro, the multi-agent layer; Standard is the complete one-agent workspace. The check is enforced in the local server, not just hidden in the browser. Everything runs against the agent runtimes already installed on your machine, over a server bound to 127.0.0.1, with no transcript upload.
Sources and related field notes
Task-board behavior, approval defaults, the overlap warning, worktree provisioning limits, and the non-destructive worktree contract were checked against the released Crowsnest source on September 3, 2026. Provider reference: Anthropic's Claude Code documentation.
Published and source-reviewed September 3, 2026. Concurrency limits and provider behavior can change between releases; the plan matrix on the pricing section is authoritative for what a given plan includes.