I've had two different AI coding agents running against the same repo for about three weeks now, and it took me embarrassingly long to figure out the thing that makes it not a disaster: git worktrees. Not a new feature, not some 2026 miracle, just a git command that's been sitting there since 2015 that nobody I know actually used until this year.
Here's the problem it solves. If you point two agent sessions at the same checkout, they both write to the same working directory, and you get the worst kind of merge conflict — the kind that happens mid-edit, where one process is halfway through rewriting a file while the other is reading it. I lost about forty minutes of an afternoon to exactly that back in June, chasing a bug that turned out to be two Claude sessions both touching auth.py at once. Not fun. Not a good use of a Tuesday.
The fix, roughly:
git worktree add ../myapp-agent-a feature/agent-a
git worktree add ../myapp-agent-b feature/agent-b
That gives you two full working directories, each checked out to its own branch, both pointing back at the same .git history. Run one agent in myapp-agent-a, the other in myapp-agent-b. They can't step on each other's files because they're not sharing files — just history. When one branch is ready, I merge it back into main the normal way and delete the worktree with git worktree remove ../myapp-agent-a.
A few things I learned the hard way:
- Node projects with a
node_modulesfolder get expensive fast if you're not careful: every worktree wants its own install unless you symlink it or use pnpm's shared store. I switched three side projects to pnpm mostly for this reason and I'm not sorry. - Give each worktree its own terminal tab, obviously, but also its own editor window if your editor caches file state per-directory (mine does, and I learned this by watching phantom diffs appear for about ten minutes before I understood what was going on).
- Don't try to run both agents against tests that write to a shared local database or a shared port. I run one on port 5173 and the other on 5174, migrated their env files to match, done.
- Naming the branches something you'll actually remember matters more than it sounds like it should. I went with
feature/agent-aandfeature/agent-bfor a while and then couldn't remember which one was doing the refactor and which one was doing the bug fix. Now I name them for the task, likefix/session-timeoutandchore/dep-bump, and my past self is much less annoying to deal with.
Is this overkill for most people? Probably. If you're only ever running one agent session at a time against one repo, none of this matters and you should ignore the whole post. But if you've gotten to the point where you're kicking off a long refactor in one session and want to poke at a small bug fix in a second session while you wait, worktrees are the boring, unglamorous answer, and boring is what you want here. I'd rather have something that's worked without surprising me since 2015 than some new tool that promises to manage agent concurrency for me and then does something clever I don't understand at 11pm.
One thing that still trips me up: worktrees share the same git config and the same hooks directory by default, so if you've got a pre-commit hook that's slow, it's slow in every worktree too. I ended up moving my linting hook to run only on staged files instead of the whole tree, which sped things up in a way that had nothing to do with agents and everything to do with a hook I'd written lazily two years ago and never revisited.
If you want to check what worktrees you've got active at any point, git worktree list shows you all of them with their branch and path. I keep forgetting this command exists and then rediscovering it every couple months, which says more about my memory than about git.
Anyway. If you're juggling more than one agent session against the same codebase and haven't tried this yet, it's maybe twenty minutes to set up and it'll save you the specific flavor of headache I had in June. Worth it.