Parallel Development with AI Agents:
Git Worktrees as a Productivity Multiplier

The Blind Spot Most Developers Have

There is a workflow mistake that almost every developer makes when first working with AI coding agents: they start an agent, wait for it to finish, review the result, merge – and then start the next agent. Serial. One after another. As if time were not a resource.

It feels tidy. It feels controlled. And it wastes most of the productivity potential that AI agents actually offer.

Simon Willison, one of the most prolific AI tooling researchers in the field, described this problem precisely in October 2025: while an agent works on Task A, your machine sits idle, the API connection waits, and the next ticket goes unstarted. In the time one agent spends 10 minutes building a feature, a second agent could already have the next feature half finished. Serial execution does not just halve your output – it thirds it.

The conceptual fix is simple: start multiple agents in parallel. The technical challenge is doing this without the agents getting in each other's way – writing to the same files, clobbering the same branches, generating merge conflicts that cost more time than the parallelism saves.

Git Worktrees solve exactly this problem. And Claude Code has built a native integration for them.

What Are Git Worktrees?

Git Worktrees are an often-overlooked feature of Git, present in the core since version 2.5 (2015) – but experiencing their breakthrough as a productivity tool only with the AI agent wave. The core idea: a single Git repository can have multiple working directories at the same time.

Normally, a repository has exactly one working directory – the folder where you see and edit your files. Everything else lives in the .git database. With worktrees you can "check out" this working directory as many times as you like – each on its own branch, in its own folder on your filesystem. All worktrees share the same .git database.

The Critical Difference from a Fresh Clone

Many developers solve the parallel work problem by cloning the repository multiple times. That works – but it has significant drawbacks:

• Every clone duplicates the entire .git database. For large repos (100 MB+) that costs time and disk space.
• Commits in Clone A are not visible in Clone B until after a git fetch and git pull.
• It is easy to lose track of which clone has which state.
• Node modules, Python virtual environments, build artifacts – everything gets duplicated unless carefully configured.

With worktrees, Git creates only a new working directory that points to a branch. The entire object database (commits, blobs, trees) continues to exist exactly once. A new worktree is created in seconds – regardless of whether the repo is 10 MB or 10 GB.

The Three Most Important Worktree Commands

# Create a new worktree (creates branch feature/payment-api and folder ../repo-payment)
git worktree add ../repo-payment feature/payment-api

# New worktree from an existing remote branch
git worktree add ../repo-auth -b feature/auth-refactor origin/main

# List all active worktrees
git worktree list

# Remove a worktree (after merging)
git worktree remove ../repo-payment

# Prune stale worktree references
git worktree prune

The output of git worktree list shows all active directories at a glance:

/home/user/my-project              a3f9b21  [main]
/home/user/my-project-payment      8c4d032  [feature/payment-api]
/home/user/my-project-auth         1e7f994  [feature/auth-refactor]
/home/user/my-project-tests        9a2c551  [feature/test-coverage]

Claude Code's Native Worktree Support

What turns Git Worktrees from a useful tool into a genuine productivity multiplier is the native integration in Claude Code – Anthropic's CLI for using Claude as a coding agent. Claude Code has two flags built specifically for the parallel worktree workflow:

# Claude Code starts in a new worktree (isolated branch)
claude --worktree

# Claude Code + tmux: agent runs in a dedicated tmux pane
claude --worktree --tmux

What happens when you run claude --worktree? Claude Code:

1. Automatically creates a new worktree – with a cleanly generated branch name based on your task description.
2. Starts the Claude session in this isolated working directory.
3. All changes made by the agent land on this branch, not on main.
4. After the task is complete, you can review, adjust, and merge – or discard the worktree.

The --tmux flag adds another layer: each agent gets its own tmux pane in your terminal. You can switch between running agents, observe progress, and intervene if needed – all in a single terminal window.

# Typical parallel workflow: starting 3 agents simultaneously
# Terminal 1: Feature A
claude --worktree "Implement Payment Integration with Stripe"

# Terminal 2: Feature B (start at the same time)
claude --worktree "Refactor Auth module to use JWT"

# Terminal 3: Tests (start at the same time)
claude --worktree "Increase test coverage to 80% for User Service"

# Or everything in one tmux session:
claude --worktree --tmux "Implement Payment Integration with Stripe"

Architecture Diagram: What Parallel Work Looks Like

The following diagram shows how a central repository is split into multiple worktrees, each with its own agent – and how the results flow back into main:

3 Concrete Use Cases

Scenario 1: Parallel Feature Development

The most obvious scenario – and the most common use case in development teams that work with AI agents in parallel. You have multiple tickets in the sprint: Feature A, Feature B, a bug fix in an unrelated module. Normally a developer would tackle these one after another, or the team would split tasks.

With parallel agents you start all three tasks simultaneously:

# Task 1: Payment Integration (Terminal 1)
cd /workspace/my-project
claude --worktree "Implement Stripe webhook handler for subscription events.
Requirements:
- Accept POST /webhooks/stripe
- Events: customer.subscription.updated, invoice.payment_failed
- Log to webhook_events table
- Retry logic on DB failure"

# Task 2: Auth Refactoring (Terminal 2, simultaneously)
cd /workspace/my-project
claude --worktree "Refactor src/auth/ from session cookies to JWT.
All existing tests must still pass.
New tests for token refresh flow expected."

# Task 3: Database Migration (Terminal 3, simultaneously)
cd /workspace/my-project
claude --worktree "Create DB migration for new user_preferences table.
Schema: user_id (FK), key VARCHAR(64), value JSONB, updated_at.
Include rollback script."

While you grab a coffee or prepare for the next meeting, all three agents run in parallel. When you return, you have three pull requests ready to review and merge. At an average task runtime of 8–15 minutes, you have waited once for 15 minutes instead of 45 minutes serially.

Important: Tasks must genuinely be independent. Payment integration and auth refactoring touch different modules – that is ideal. If both agents were to work on src/middleware/auth.ts, merge conflicts would be guaranteed.

Scenario 2: Model Comparison – Claude Opus 4.8 vs. Codex vs. GPT-5.5

A particularly powerful scenario: you send the same task to three different models simultaneously and compare the results. This might sound inefficient – but it is not, when you face a complex implementation decision and want to know which approach is best.

Practical example: you need to implement a caching strategy for a high-traffic API. Redis? In-memory LRU? Edge caching? Three models, three approaches – you review the differences and pick the best:

# Create worktrees
git worktree add ../project-cache-claude  -b experiment/cache-claude
git worktree add ../project-cache-codex   -b experiment/cache-codex
git worktree add ../project-cache-gpt     -b experiment/cache-gpt

# Start agents (different models, same task)
cd ../project-cache-claude && claude --model opus "Implement caching for GET /api/products..."
cd ../project-cache-codex  && codex "Implement caching for GET /api/products..."
cd ../project-cache-gpt    && gpt-code "Implement caching for GET /api/products..."

# Compare results
git diff experiment/cache-claude experiment/cache-codex -- src/cache/
git diff experiment/cache-claude experiment/cache-gpt   -- src/cache/

What you will regularly observe: the models choose different abstraction levels. Claude Opus 4.8 tends toward more complete implementations with error handling and tests. Codex often produces more compact code that stays closer to the existing patterns in the repository. GPT-5.5 frequently shines with well-thought-out types and interfaces.

The outcome is not a question of "which model is better" but which approach fits this specific codebase, this team, and these requirements.

Scenario 3: Scout Mode – Explore Without Commitment

Scout mode is a pattern Simon Willison described in his October 2025 post, and it is extremely valuable in practice: you send an agent into a worktree to answer a question without intending to merge the code.

Typical scout questions:

• "How hard would it be to migrate this module to TypeScript 5.x?"
• "Which tests break if we switch the database connection to connection pooling?"
• "Can our API layer support GraphQL without breaking the REST endpoints?"

# Create scout worktree
git worktree add ../project-scout -b scout/typescript-migration

# Agent explores – no merge planned
cd ../project-scout
claude "Try to migrate src/api/ to TypeScript 5.5.
Write a summary at the end:
- How many files need to change?
- What breaking changes are there?
- Estimate: how many hours of manual work?
You do NOT need to fix everything, just explore and report."

# After the scout: read result, then remove worktree
cat SCOUT_REPORT.md
git worktree remove ../project-scout

The key advantage: the scout agent can and should make mistakes, leave incomplete implementations behind, break tests – that is intentional. The output is not mergeable code but an effort estimate and risk assessment. For planning conversations and sprint estimates, that is invaluable.

Quick-Start Guide: Parallel Workflow in 10 Minutes

Here is the complete step-by-step guide to get started with parallel AI agents on worktrees immediately:

Step 1: Prepare the Repository

# Make sure main is clean
git checkout main
git pull origin main
git status  # no uncommitted changes!

Step 2: Create Worktrees

# Pattern: [parent-dir]/[repo]-[ticket-id]
git worktree add ../my-project-123 -b feature/TICKET-123
git worktree add ../my-project-124 -b feature/TICKET-124
git worktree add ../my-project-125 -b feature/TICKET-125

# Verify all worktrees
git worktree list

Step 3: Copy .env Files

# .env is in .gitignore – copy manually
cp my-project/.env ../my-project-123/.env
cp my-project/.env ../my-project-124/.env
cp my-project/.env ../my-project-125/.env

# Optional: script for automatic setup
cat > setup-worktree.sh << 'EOF'
#!/bin/bash
WT_PATH=$1
cp .env "$WT_PATH/.env"
echo "Worktree $WT_PATH ready."
EOF
chmod +x setup-worktree.sh

Step 4: Start Agents in Parallel

# Option A: Separate terminals
# Terminal 1:
cd ../my-project-123 && claude "TICKET-123: ..."
# Terminal 2:
cd ../my-project-124 && claude "TICKET-124: ..."
# Terminal 3:
cd ../my-project-125 && claude "TICKET-125: ..."

# Option B: tmux (all in one window)
tmux new-session -d -s agents
tmux send-keys -t agents "cd ../my-project-123 && claude --worktree 'TICKET-123...'" Enter
tmux split-window -h
tmux send-keys -t agents "cd ../my-project-124 && claude --worktree 'TICKET-124...'" Enter
tmux split-window -v
tmux send-keys -t agents "cd ../my-project-125 && claude --worktree 'TICKET-125...'" Enter
tmux attach -t agents

Step 5: Review and Merge

# Review diff before merging
cd ../my-project-123
git diff main...HEAD

# Run tests
npm test

# Go back to main repo and merge
cd my-project
git merge feature/TICKET-123
git merge feature/TICKET-124
git merge feature/TICKET-125

# Clean up worktrees
git worktree remove ../my-project-123
git worktree remove ../my-project-124
git worktree remove ../my-project-125
git worktree prune

Best Practices and Common Pitfalls

How This Works with OpenClaw

Teams using OpenClaw as their agent framework get native support for parallel worktree workflows – with considerably more comfort than the manual approach using the Claude Code CLI.

OpenClaw has had a built-in Worktree Dispatcher since version 0.8, which automatically distributes tasks to available worktrees. The core principle:

1. Task Queue: You pass multiple tasks to OpenClaw. The dispatcher orders them by dependency and resource contention.
2. Automatic Worktree Management: OpenClaw creates worktrees, copies .env files, and configures the correct branch automatically.
3. Parallelisation: Independent tasks run simultaneously. Dependent tasks wait for their prerequisites.
4. Review Dashboard: All results land in a central review interface – you see the diff, can provide feedback, and merge or reject with one click.
5. Cleanup: After merging, worktrees are automatically removed and branches cleaned up.

# OpenClaw parallel task queue
openclaw dispatch \
  --task "TICKET-123: Payment Integration" \
  --task "TICKET-124: Auth Refactoring" \
  --task "TICKET-125: DB Migration" \
  --parallel \
  --model claude-opus-4-8 \
  --review-before-merge

# OpenClaw automatically starts 3 worktrees and shows dashboard
> Dispatching 3 tasks to parallel worktrees...
> worktree-1 [feature/ticket-123]: RUNNING (Claude Opus 4.8)
> worktree-2 [feature/ticket-124]: RUNNING (Claude Opus 4.8)
> worktree-3 [feature/ticket-125]: RUNNING (Claude Opus 4.8)
> Open dashboard: http://localhost:8080/review

For enterprise teams running OpenClaw on-premises, Clawgency additionally provides a central monitoring system that makes all parallel agent activities visible in real time – including token consumption, runtimes, and an audit log for GDPR compliance.

FAQ: All Questions About Parallel AI Agents with Git Worktrees