Parallel Claude Code sessions with git worktrees

A Claude Code session is fast, but it's still one session in one working directory. Start a second one in the same checkout and they fight: both editing the same files, both mutating the same git index, both tripping each other's file watchers. Agents made writing code parallel-cheap, but a checkout is still a single-threaded resource. You don't need a bigger agent for that. Git already shipped the fix, a decade ago: git worktree.

A worktree is an extra working directory attached to the same repository: same object store, same remotes, its own checked-out branch. That yields the pattern: one repo, several worktrees, one Claude Code session in each. Three features progressing in parallel on one laptop, no containers, no cloud queue, nobody stepping on anybody.

The setup

git worktree add ../app-auth feature/auth
git worktree add ../app-search feature/search
git worktree add ../app-experiment spike/orm-swap

Open a terminal tab per directory, run claude in each, give each session its own task. The details that make it work day to day:

• Untracked state is per-worktree. node_modules, .env, and build caches each need their own install. Budget the disk space and the setup minutes.
• CLAUDE.md rides along for free. It lives in the repo, so every session gets the same steering with zero extra setup.
• Ports collide even when files don't. Two dev servers wanting the same port will fight. Give each worktree its own via env and say so in the task prompt.
• Cleanup is one command. git worktree remove ../app-auth once the branch merges, and git worktree list for the day you forget what is running where.

A padded room for risky experiments

Parallel features are the obvious use; disposable experiments are the better one. "What would it take to swap the ORM" is exactly the kind of question agents answer well and working trees suffer for. Spin up a worktree, hand the agent the whole migration with a loose leash, and judge the result. Promising? Clean it up into a real branch. Garbage? git worktree remove --force and the experiment never existed. Maximum agent autonomy, blast radius of one disposable directory.

Worktrees give every agent session its own copy of the world, and make destroying a bad world cheaper than reviewing it.

When local beats cloud

Codex's answer to the same problem is a fleet of cloud sandboxes, and the cloud route has real virtues. But local worktrees win whenever the environment is the hard part (seeded databases, private registries, the toolchain that took a week to configure) because every worktree inherits your machine exactly. They win when you want to inspect an agent mid-flight with your own editor and debugger rather than a web diff. Cloud wins when the laptop needs to close, or when the session count outgrows what one machine and one human can host. It is the same dividing line I drew in async agent architecture: interactive iteration wants local, fire-and-forget wants remote.

Merge discipline is the new bottleneck

Here is the honest cost. Three sessions produce branches faster than you can integrate them, and integration is the one job you cannot delegate. The pattern only holds with discipline: one concern per branch, rebase onto main early and often so conflicts surface while they are small, review every PR as if a stranger wrote it. Functionally, one did. And know your ceiling: for me, somewhere past three concurrent sessions supervision turns into skimming, which quietly converts parallelism into deferred rework. The bottleneck never disappeared. It moved from writing code to judging it, which is where it belonged all along.

Start with two worktrees: the feature you are on and the experiment you keep postponing. If Friday's log shows both branches merged, you have earned a third lane. If it shows two half-reviewed piles, you have found your ceiling instead, and that is worth knowing too.