Run Claude Code agents in parallel without collisions
Two agents writing in one checkout can entangle or overwrite uncommitted work. Give each writer a separate directory—usually a detached worktree—or serialize the writes and approve them 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.
Where Crowsnest fits today.
Crowsnest can keep several ordinary Claude Code or Codex conversations running and shows provider-native subagents and background jobs inside the conversation that launched them. Each conversation keeps its own native history, approvals, Stop control, and follow-up composer.
It does not provision worktrees, dispatch a separate task board, or coordinate overlapping writers. If you run concurrent agents, create and review their isolation with the provider or development tools you already trust; Crowsnest is the local place to inspect their conversations, activity, and handoffs afterward.
The earlier Crowsnest parallel board and Crew workflow were retired in October 2026 after proving unused. This article remains as a workflow guide because its isolation and review rules still apply to provider-native parallel work.
Sources and related field notes
The current-product section was rechecked against the Crowsnest source on October 19, 2026. Provider reference: Anthropic's Claude Code documentation.
Published September 3, 2026; current-product claims reviewed October 19, 2026. Crowsnest no longer ships its former parallel board or Crew orchestrator.