Parallel AI coding agents with git worktrees

A git worktree is a linked working directory attached to an existing repository. Unlike a second clone, which duplicates the whole object database, a worktree shares history and objects with the main checkout while giving you a fully independent directory on a different branch. Git has shipped worktrees since version 2.5 in 2015; most developers never needed them until background coding agents made "several branches checked out at once" the normal case.

# create a worktree one level up, on a new branch
git worktree add ../my-feature feature/my-feature

# list all worktrees attached to this repo
git worktree list

# remove when done, then clean up stale metadata
git worktree remove ../my-feature
git worktree prune

What each worktree owns, and what all of them share:

The most common mistake when running multiple AI agents is pointing them all at the same branch in the same directory. Three failure modes show up almost immediately:

Worktrees eliminate all three. Each agent gets its own directory, its own branch, its own index, and its own ports. The only coordination point is shared git history, which agents read until they push their own branch, agents share nothing except the foundation they branched from. That isolation is one of the few hard guarantees in a multi-agent coding workflow; most other safeguards are conventions.

This is the workflow many experienced developers run today, and it's the foundation an orchestrator automates. It works with Claude Code, Codex CLI, or a mix.

1. 1

   Create a worktree per task

   From your main checkout, create one worktree and branch for each parallel task. Each directory gets a fresh checkout of its own new branch.

   git worktree add ../project-auth feature/auth
   git worktree add ../project-payments feature/payments
   git worktree add ../project-notifications feature/notifications

2. 2

   Open a terminal in each worktree

   cd into each directory in its own terminal tab or tmux pane. Every command from here on, npm install, npm run dev, git commit, affects only that worktree's branch.
3. 3

   Launch an agent in each

   Run claude (or codex) in each terminal and give each agent its task. Isolated directory, isolated branch: the agent can commit, run tests, and start a dev server without coordinating with anyone.

   cd ../project-auth && claude
   cd ../project-payments && claude
   cd ../project-notifications && codex

4. 4

   Track progress by hand

   This is where the manual approach strains. With three panes it's manageable; with five you're constantly cycling tabs to find out which agent is blocked, which committed, and which is waiting on you.
5. 5

   Push, open PRs, clean up

   For each finished task: push the branch, open a PR, remove the worktree. At five parallel tasks this is 15+ commands per cycle.

   git push -u origin feature/auth
   gh pr create
   git worktree remove ../project-auth
   git worktree prune

The workflow is entirely valid, nothing here is a hack. The cost is bookkeeping: worktree lifecycle, terminal juggling, and per-branch PR ceremony, multiplied by every parallel task, every cycle.

An orchestrator's job is to make steps 1, 4, and 5 disappear. AIDEN, a desktop workspace that runs your existing Claude Code and Codex CLIs, handles the worktree and PR plumbing around each task. The broader session-management picture is covered in Claude Code orchestration.

Git isn't the constraint, it handles hundreds of worktrees without complaint. The honest answer is "it depends", on three things you can reason about:

In practice most people cap out on review attention long before hardware. Start with two or three parallel stories, notice where your queue backs up, and scale from there, the goal of an agentic IDE workflow is more reviewed, merged work, not more concurrent processes.