DevOps
Parallel Claude Code Agents With Git Worktrees
August 20269 min read
A git worktree is an additional working directory attached to the same repository, each with its own checked-out branch but sharing one object database. With Claude Code it lets you run several sessions at once, each in its own folder, so the agents never overwrite each other's files. It is the cleanest way to parallelize independent tasks.
Use git worktree add to create a new folder on its own branch, then open a separate Claude Code session inside it. Give each session a single, self-contained objective, review and merge each branch on its own, and remove finished worktrees with git worktree remove. Naming each worktree after its task keeps the layout easy to follow.
They can. Worktrees isolate files but not runtime resources, so two agents that start a dev server on the same port, migrate the same database, or write to a shared cache will still interfere. The fix is to give each worktree its own port, database or schema, and dependency install where the ecosystem needs it.
Yes. Each agent runs its own session and consumes its own tokens, so three agents can burn roughly three times the tokens of one. Parallelism is a force multiplier for genuinely independent work, but it is wasteful for tightly coupled tasks where you spend more effort resolving conflicts than you saved.
When tasks are tightly coupled or when your own review capacity is the bottleneck. Three agents produce three diffs, and unreviewed parallel output is a liability rather than a win. Parallelize only work that is truly independent, and stop adding agents once you can no longer review their output carefully.
Key Takeaway
Git worktrees check out several branches into separate folders from one repository, so you can run multiple Claude Code sessions at once without them overwriting each other's files. It is the cleanest way to parallelize independent tasks, but it multiplies token cost and demands that you isolate ports, databases, and dependencies per worktree.
One of the fastest ways to get more out of Claude Code is to stop running it one task at a time. If you have three independent pieces of work, three agents can move on them at once. The obstacle is not the tool; it is that a single working directory cannot hold three divergent sets of changes without chaos.
Git worktrees remove that obstacle. This guide explains the collision problem, how worktrees solve it, a workflow for driving several agents in parallel, and the runtime pitfalls that catch people the first time.
A normal clone has a single working directory tied to one checked-out branch. Point two Claude Code sessions at it and they edit the same files, stage over each other, and force you to keep switching branches, which resets everyone's in-progress work. Parallel agents in one directory do not cooperate; they corrupt each other.
You could clone the repository several times to sidestep this, but full clones are wasteful and drift apart. The friction shows up as:
A git worktree is an additional working directory attached to the same repository. The command git worktree add creates a new folder with its own checked-out branch while sharing the underlying object database, so you get isolated files without duplicating the repository's history. Each worktree is a clean, independent stage.
With a worktree per task, you open a separate Claude Code session in each folder. The agents never touch each other's files because, on disk, they are working in different directories on different branches. When a task is done you merge its branch and remove the worktree with git worktree remove.
Name each worktree after its task and keep them in a sibling folder next to the main checkout, not inside it. A predictable layout makes it obvious which agent owns which directory and keeps stray worktrees out of your primary working tree.
Once worktrees are in place, a repeatable loop keeps several agents productive without losing track of them.
Worktrees isolate files, but they do not isolate everything else your project touches at runtime. Two agents that each start a dev server on the same port, migrate the same database, or write to a shared cache will still interfere even though their source trees are separate.
The fix is to make the runtime as isolated as the files: assign each worktree its own port, its own database or schema, and its own dependency install where the ecosystem needs it. A little per-worktree configuration up front prevents confusing failures that look like bugs but are really two agents fighting over one resource.
Worktrees isolate the filesystem, not the running system, and parallelism multiplies token cost. Three agents can burn roughly three times the tokens of one, and shared ports or databases will still collide. Parallelize only genuinely independent work, and confirm the runtime is isolated before you press go.
Running many agents is a force multiplier for the right work and a distraction for the wrong work. The deciding factor is usually how independent the tasks are and how much review you can absorb.
Git worktrees are the cleanest way to run Claude Code agents in parallel because they give each session its own files while sharing one repository. Pair them with isolated ports and databases, parallelize only independent tasks, and remember that your review bandwidth, not the tool, sets the real limit on how many agents you can usefully run.