Founder pricing: Pro at $9.99/mo forever for the first 50 members. 18 of 50 left Claim yours →
All posts

How to use git worktrees to run AI coding agents in parallel

The SanuDesk team 5 min read
git worktrees ai agents workflow

The first time you run two AI coding agents in the same repository, you find out the hard way that they share everything. Agent one is halfway through a refactor when agent two runs the test suite, against a tree full of agent one's unfinished edits. git status turns into a crime scene nobody will admit to. Sooner or later, one agent helpfully commits the other's work in progress.

None of this is the model's fault. Two capable agents in one folder are two fast typists sharing one keyboard. The fix has been sitting inside git since 2015: worktrees.

What a git worktree actually is

A worktree is a second (or fifth) full checkout of the same repository, in its own folder, sharing one underlying history. Where git clone copies everything, a worktree reuses the repo you already have, so creating one is near-instant:

# from inside your repo
git worktree add -b agent/payments ../myapp-payments
git worktree add -b agent/flaky-tests ../myapp-flaky-tests

You now have sibling folders, each a complete working copy on its own branch. Edits in one are invisible to the others until they're committed and merged, which is exactly the isolation a fleet of agents needs.

Two commands round it out: git worktree list shows every checkout, and git worktree remove ../myapp-payments cleans one up once its branch is merged. Git even enforces the golden rule for you: the same branch can't be checked out in two worktrees at once, so agents can't end up sharing a tree by accident.

The workflow: one task, one worktree, one agent

The pattern that works is almost boring:

  1. Cut a worktree per task, with a branch named after it.
  2. Start each agent in its own worktree folder. As far as the agent knows, it owns the entire repository.
  3. Let it commit on its branch. No stepping on other agents, no mixed diffs, no lost work when something crashes. Add a rule for commit size to the brief and the branch arrives as changes you can revert one at a time, not one you review in a single sitting.
  4. Review each branch like a pull request, merge what passes, then remove the worktree. Order matters once several branches land the same afternoon: merge the shared-code branch first and rebase the rest onto it.

That last step matters more than it looks. Each branch is a clean, attributable diff (one task, one author, one change), which makes reviewing AI-generated code dramatically easier than untangling three agents' edits from one shared tree.

The honest costs

Worktrees aren't free, and most guides skip this part:

  • Dependencies don't come along. node_modules, vendor and build caches are untracked, so every new worktree needs its own install. That's disk space and a few minutes each time.
  • Neither do secrets. .env files are untracked too, so copy them in as part of your setup, or an agent burns ten minutes discovering the app won't boot.
  • Ports collide. Two dev servers in two worktrees both want port 3000. Give each worktree its own port and the problem disappears.
  • They pile up. Stale worktrees linger after the merge. Run git worktree list now and then, and remove what's done.

And sometimes you don't need them at all. Agents doing read-only research, or working in different repositories entirely, can't conflict in the first place. Worktrees earn their keep when several agents are writing to the same repo at once. And in a monorepo, scoping each agent to one package removes half those collisions before worktrees pick up the rest.

The git problem is solved. The human problem isn't.

Here's what actually breaks after the setup: you now have four near-identical folders and four agent sessions, and everything looks the same. Which terminal is the payments worktree? Which agent finished twenty minutes ago and has been idle since? It's the same wall you hit running multiple Claude Code agents in a pile of terminal tabs, multiplied by folders that didn't exist yesterday.

That management layer is what SanuDesk is for. A workspace is just a folder, so each worktree becomes its own workspace, with its own accent color, so the payments checkout never gets mistaken for the tests one. Sessions tile into a single grid, every agent visible at a glance whichever checkout it's in. And instead of typing prompts into each terminal, you write cards on a Kanban board and deploy them: each card becomes an agent's brief and lands in In Review with a "what changed / how to test" note the moment the agent stops, so merge-and-remove decisions happen in one lane. It drives the Claude Code, Codex and Gemini accounts you already pay for, and the desk is free.

One human, several checkouts, a whole fleet shipping in parallel, without a single stepped-on diff.

The short version

Give every agent its own checkout (git worktree add), its own branch, and its own brief. Budget for the real costs (dependency installs, env files, ports) and clean up merged worktrees. Then solve the half git can't: seeing the whole fleet and feeding it work from one place.

Download SanuDesk free and point a workspace at each worktree, or see how the grid, the board and Loops fit together on the features page.

Run your own fleet of agents

SanuDesk is a free desktop app that tiles your Claude Code and Codex sessions and gives every project a Kanban board your agents work from.