The pitch for parallel Claude Code agents is usually speed. That is the wrong frame. The real product of running agents in git worktrees is isolation, and I say that as someone whose repo makes the stakes unusually concrete: on mejba.me, every push to main auto-deploys to my live production site within about ninety seconds. An agent that commits to the wrong branch on my machine is not a merge inconvenience. It is a production deploy.
So this is not a post about a theoretical 3x productivity multiplier. It is the working setup I use to run multiple agents against one production repository without any of them being able to hurt me, plus the one gotcha that sends agent commits straight to main if you have not configured against it.
What a real parallel session looks like
Most of my multi-agent sessions have the same shape: one orchestrator, several scoped workers. A concrete example from this repo: a site-wide content remediation where an orchestrator held the task list and dispatched worker agents, each assigned ten blog posts, a fixed output directory, and a mandatory backup step before touching anything. The workers never talked to each other and never shared files. The orchestrator merged results at the end.
That shape repeats across the real work I have shipped this way: services page overhauls, portfolio cleanups, SEO fixes across dozens of pages, each landing as its own reviewable pull request. The pattern that makes it work has three rules:
- Each agent owns a disjoint set of files. Not "mostly disjoint." Disjoint.
- Each agent produces a deliverable, not an opinion. A branch, a set of files, a PR.
- Nothing merges without me reading the diff. Parallelism multiplies output, which multiplies review load. Plan for it.
Worktrees are the mechanism that makes rule one enforceable rather than aspirational.
Git worktrees in sixty seconds
A worktree is an additional working directory attached to the same repository. One .git database, multiple checkouts, each on its own branch:
# from your main checkout
git worktree add ../mejba-feature-a -b feat/feature-a
git worktree add ../mejba-feature-b -b feat/feature-b
git worktree list
# /Users/mejba/Herd/mejba.me 960efc6 [main]
# /Users/mejba/Herd/mejba-feature-a abc1234 [feat/feature-a]
# /Users/mejba/Herd/mejba-feature-b def5678 [feat/feature-b]
Each directory is a full checkout. An agent working in mejba-feature-a physically cannot dirty the files an agent in mejba-feature-b is editing, because they are different inodes on disk. When the work merges, remove the worktree:
git worktree remove ../mejba-feature-a
Two practical notes that guides skip. First, worktrees share the repo's hooks: my pre-commit hook (Pint blocks the commit, PHPStan warns) runs identically in every worktree, so every agent inherits the same quality floor without any per-agent setup. Second, worktrees are full checkouts of tracked files, so a large repo times N agents costs real disk. Clean up when branches merge.
I do not even create these by hand anymore. Claude Code can manage the lifecycle itself; I use a skill (using-git-worktrees from the superpowers plugin, which I covered in my superpowers plugin review) that creates the isolated workspace before feature work starts and tears it down after. The point is not the specific tooling, it is that workspace isolation happens by default, not by discipline.
The gotcha: agent commits landing on main
Here is the failure mode that makes isolation mandatory rather than nice-to-have.
A fresh worktree branch has no upstream. Depending on your git config, an agent (or you) running git push from that worktree can end up pushing somewhere you did not intend, and an agent that starts work without checking out a branch at all will happily commit directly to whatever is checked out, which in the primary worktree is usually main. Agents are obedient: if the working directory is on main, they commit to main.
On most repos that costs you an embarrassing revert. On mine, main is wired to a GitHub Actions pipeline that rsyncs to production, the same pipeline I documented in my automatic Laravel deployment setup. The blast radius of a sloppy agent commit is a live site.
Three layers of defense, all cheap:
Layer 1: a written rule agents actually read. My CLAUDE.md contains a one-line law: if on the default branch, branch first. Claude Code reads that file every session. Since adding it, "agent committed to main" has simply stopped happening to me.
Layer 2: git config. Make new branches track a same-named remote branch automatically, so a bare git push from a worktree can never surprise you:
git config --global push.autoSetupRemote true
Layer 3: branch protection. Protect main on the server side. Require PRs. Even if layers one and two fail, the push bounces.
None of these three is sufficient alone. Together they have held across months of daily agent sessions on a repo where the cost of failure is public.
What parallelizes well (and what never does)
After a lot of sessions, my honest sorting:
Good parallel candidates
- Batch content transformations (N items, one worker per slice, disjoint outputs)
- Backend feature plus frontend feature that meet only at an already-defined interface
- Test-writing against code another agent is not currently editing
- Repetitive refactors across independent modules
- Two competing implementations of the same idea, built as disposable experiments, where you keep the winner and delete the loser
Never parallel
- A migration and the code that depends on the migrated schema
- Two tasks that both touch your routes file, config, or any other high-traffic shared file
- Anything where task B needs task A's output; that is a sequence wearing a parallelism costume
- Exploratory debugging; two agents chasing one bug will happily construct two contradictory theories
The test I apply before dispatching: can I write each agent's file boundary in one sentence? If the boundaries need a paragraph, the tasks are not independent, and worktrees will not save the merge.
Review is the bottleneck, so design for it
Three agents produce three diffs, and reading diffs is now most of your job. What keeps it manageable for me:
- One PR per worktree, always. Focused diffs with no cross-contamination. A PR that mixes two concerns gets split before review, not after.
- The hooks pre-review everything. Formatting and static analysis complaints are already handled by the time I look, so review attention goes to logic.
- Verification evidence in the handoff. Each worker ends by stating what it ran (targeted tests, lint, build) and what passed. An agent that must report its verification does more of it.
- Merge one, rebase the rest. After the first branch lands, the other worktrees rebase onto the new
mainbefore their PRs merge. Doing this immediately keeps conflicts trivial.
If you are scaling past a couple of concurrent workers, the coordination patterns matter more than the git mechanics; I wrote up the team-shaped version separately in my agent teams setup guide.
The honest limits
Worktrees are cheap but not free. Disk usage is real on big repos. Dependency directories (vendor/, node_modules/) either get installed per worktree, which is slow, or shared through symlinks, which occasionally confuses tooling. And there is a human ceiling nobody markets: around three concurrent agents, my ability to review output stops scaling, and unreviewed agent code is exactly as trustworthy as unreviewed human code, which is to say not at all.
The other limit worth naming: parallelism only pays when the work genuinely splits. I still do most of my day sequentially, one agent, one task, full attention. The parallel setup comes out for batch work and cleanly separable features, which in a normal week is maybe a third of the workload. Matching the technique to the task shape beats maximizing agent count.
Start with two, not five
The minimal adoption path runs like this: pick two genuinely independent tasks, create two worktrees with the commands above, set push.autoSetupRemote, add the branch-first line to your CLAUDE.md, and run one agent in each directory. Merge both PRs, remove both worktrees. The whole experiment costs an hour and teaches you more than any post can, including this one.
Worktree parallelism is one module of the agentic development stack I run day to day, and the structured version — with exercises rather than blog-post assembly — sits in my AI School.
