Git Worktrees for Running Multiple AI Coding Agents

Ask an AI coding agent to fix a bug and it edits your working directory. Ask a second agent to add a feature at the same time, in the same directory, and you have two processes racing to write the same files. One of them will lose, and you won't always notice until a stray edit shows up in a diff you didn't expect, or a test fails for a reason that has nothing to do with the code you actually wrote.

The fix isn't a special multi-agent framework. It's a Git feature that predates any of these tools by a decade: git worktree. A worktree gives each agent its own real, on-disk checkout — its own branch, its own files, its own working state — while every worktree still shares one .git history underneath. No duplicated clones, no merge surprises mid-task, and no agent able to see another agent's half-finished edit.

This post is about that mechanism: what it actually does, how to use it by hand with any terminal agent, and which tools in the vibe-coding ecosystem have already built a nicer interface on top of it.

What a git worktree actually is

A normal Git repository has one working directory checked out to one branch at a time. If you want to look at two branches simultaneously, your only options used to be a second git clone (which duplicates the whole history on disk and needs its own remote tracking) or constant git stash and git checkout gymnastics to swap between them in place.

git worktree add solves this properly. It creates a second working directory, linked to the same repository, checked out to a branch of its own:

# from inside your main checkout
git worktree add ../myproject-feature-a -b feature-a
git worktree add ../myproject-bugfix-12 -b bugfix-12

Now ../myproject-feature-a and ../myproject-bugfix-12 are two independent folders with their own files, their own git status, and their own uncommitted changes — but a single shared object database. Committing in one worktree doesn't touch the other, and a git log in either one shows the same shared history. You can list every worktree attached to a repo with:

git worktree list

This has existed in Git since version 2.5 (2015), originally aimed at humans who wanted to build on main and hotfix a release branch without stashing in-progress work. AI coding agents have simply given the feature a second life.

Why this matters specifically for agents

A terminal coding agent doesn't just read files — it writes them, runs your test suite, and sometimes reverts its own changes mid-task. Point two agent sessions at the same working directory and you get real failure modes, not theoretical ones:

• Agent A is mid-edit on auth.py when Agent B's test run reads a half-written file and reports a false failure.
• Agent A commits, then Agent B — still working from a stale view of the tree — stages and commits over part of that change.
• One agent's rm -rf node_modules && npm install yanks the dependency tree out from under the other agent's currently-running dev server.

None of this is exotic; it's just what happens when two writers share one working directory with no locking. Worktrees sidestep the whole class of problem by giving each agent a directory nothing else touches. There's a secondary benefit too: an agent working in a clean, single-purpose worktree doesn't have to reason about unrelated changes sitting in the tree from a different task, which keeps its context focused on the diff it's actually responsible for. You still get one shared Git history to review, diff and merge from — you just stop the agents from literally overwriting each other's files while they work.

The manual workflow with any agent

You don't need a special tool to try this today. Here's the pattern with a terminal agent like Claude Code, though it works identically with any agent that operates on the current directory:

cd ~/code/myproject

# spin up two isolated worktrees for two tasks
git worktree add ../myproject-a -b agent/rate-limiting
git worktree add ../myproject-b -b agent/csv-export

# run one agent per worktree, in separate terminal tabs
cd ../myproject-a && claude
cd ../myproject-b && claude

Claude Code Paid

Anthropic's agentic coding tool for the terminal, IDE, desktop and web

★ 149k · +863 this week

🔥 Claude Pro billed annually: $17/month instead of $20

9.4 Visit ↗

Each session only sees its own checkout. When a task is done, review and merge like you would any branch:

cd ~/code/myproject
git diff main..agent/rate-limiting
git merge agent/rate-limiting

Two things worth knowing before you script this yourself. First, a branch already checked out in one worktree can't be checked out a second time elsewhere, which is why the commands above create a fresh branch per task rather than reusing one. Second, anything not tracked by Git — a node_modules folder, a .env file, build artifacts — does not automatically appear in a new worktree. Plan on re-running your install step per worktree, or symlinking a shared, read-only dependency cache in if the size adds up.

Cleaning up when you're done

Worktrees are cheap to create but they do sit on disk until you remove them. When a task's branch has been merged and you don't need the checkout anymore:

git worktree remove ../myproject-a
git worktree prune

git worktree remove refuses to delete a worktree with uncommitted changes unless you pass --force, which is a useful safety net if an agent left work in progress you forgot about. git worktree prune cleans up Git's internal bookkeeping for worktrees whose directories were already deleted manually (say, with rm -rf) instead of through git worktree remove. If you skip cleanup entirely, git worktree list becomes the easiest way to periodically audit what's still lying around before it eats disk space, especially in a monorepo where each worktree carries its own full dependency install.

Tools that automate this for you

Running two git worktree add commands by hand is fine for two agents. It gets tedious past three or four, especially once you want a dashboard showing which agent is idle, which is blocked, and which produced a diff worth reviewing. A few tools in the directory build exactly that layer on top of worktrees:

Claude Squad 🤖 AgentFree

Manage multiple terminal agents in parallel in separate workspaces

★ 8.6k · +28 this week

7.7 GitHub ↗

Emdash Free

Run multiple coding agents in parallel, each in its own isolated Git worktree

★ 5.9k · +58 this week

7.5 Visit ↗

Subtask 🤖 AgentOpen source

Claude Code skill and CLI to run tasks as subagents in parallel Git worktrees

★ 339 · +-1 this week

6.5 GitHub ↗

cc-haha Open source

Local-first desktop workspace for Claude Code and other agents, with worktrees and diffs

★ 15k · +125 this week

7.0 GitHub ↗

They differ mainly in where you sit while supervising the work. Claude Squad and Subtask keep you in the terminal — Claude Squad multiplexes tmux panes around each worktree, while Subtask hands the whole spawning decision to Claude Code itself as a skill, so you never leave your existing session. Emdash and cc-haha put a GUI on top, which pays off once you're fanning a task out to more than one agent provider (Claude Code, Codex, Cursor in the same run) rather than just multiple instances of the same one, since comparing outputs from different providers benefits from a visual diff side by side.

When worktrees aren't the right tool

Worktrees solve file isolation. They don't solve everything a parallel-agent setup runs into:

• Shared external state. Two agents in two worktrees can still both write to the same local Postgres database, the same dev server port, or the same cloud resource. Worktrees isolate the checkout, not your infrastructure — you'll still want separate ports, databases or sandboxed environments for tasks that touch running services.
• Database migrations. If both tasks add or modify a schema migration, the migrations themselves will conflict at merge time even though the worktrees never collided on disk — this is a modeling problem worktrees can't solve for you.
• A single small task. If you're making one focused change, a second worktree is pure overhead. This pays off once you're genuinely running two or more agents concurrently, not for every session.
• Disk-heavy dependency trees. Untracked directories like node_modules aren't shared between worktrees, so each one needs its own install. For large monorepos this can mean gigabytes duplicated per worktree.
• Long-lived merge conflicts. Worktrees make it easy to let branches diverge for a while. That's the point, but it also means the eventual merge can be larger and more conflict-prone than if the same work had happened serially on one branch.

A concrete workflow to try this week

Pick a repo where you already have two independent, well-scoped tasks queued up — a bug fix and a small feature, say, neither depending on the other's changes. Create two worktrees, open a terminal agent in each, and give each one a single task rather than a vague "work on whatever." Review both diffs against main before merging either one, in whichever order finishes first.

If that goes well and you find yourself doing it two or three times a week, that's the signal to graduate to one of the orchestration tools above rather than keep typing git worktree add by hand. Claude Squad is the lowest-friction next step if you're already comfortable in tmux; Emdash is worth it the moment you want to compare two different agent providers on the same task rather than two instances of one; Subtask is worth trying first if you'd rather stay inside a single Claude Code session and let it manage the spawning itself.

Takeaway: the multi-agent tooling landscape looks more novel than it is. Underneath almost every "run several coding agents in parallel" product is the same decade-old Git primitive — a worktree per task, one shared history to merge from. Learn the three commands (add, list, remove) before you adopt a tool that wraps them; you'll understand what the tool is actually buying you, and you'll have a fallback for the day it isn't installed.

For more on running several agents side by side, browse MCP servers that pair well with a multi-agent setup, check current deals on the apps mentioned here, and see the glossary if any of the Git terms above are new.