Run git worktree list on the machine where you have been running agents for a
month. If the output is a screen and a half, and half of it merged weeks ago,
this post is about you.
Eight of the twelve tools we checked on 1 August 2026 isolate each task in a git worktree. That is not a feature separating them from each other. It is the floor they all stand on, and git has had it since 2.5 shipped in 2015.
What a git worktree gives you, and when it stopped being interesting
A git worktree is a second checkout of the same repository, on its own branch, in its own directory, sharing one object store. Two agents in two worktrees cannot overwrite each other's files, which is the whole problem it solves.
git worktree add ../repo-auth-retry -b agent/auth-retryThat command is the entire moat that most of this category advertises. It is one line, it is free, and it was solved before any of these tools existed. A feature list that opens with worktree isolation is describing the floor.
The three costs that grow instead
Isolation is a fixed cost you pay once per task. Everything around it grows.
The first is cleanup. A finished worktree holds a branch, a build directory, and whatever the agent left lying around, and nobody schedules the Friday afternoon where they deal with forty of them. So the repository turns into a junk drawer and stays one.
The second is the files git does not track. A fresh worktree has no .env and
no local config, so each new one starts with an agent finding out your build
does not run and spending its first turns working out why. Cheap to fix once,
annoying forever if you do not.
The third is reading, and this is the one that never shrinks. Ten worktrees produce ten changesets. The number of people available to read them is the same number it was before you automated anything.
What the category argues about, and what it skips
Read the marketing in this space and the argument is about the launcher. Terminal against desktop app. One agent against ten. Your machine against somebody's cloud. Every position in that argument is about the writing half, and all twelve tools write code in parallel perfectly well.
Two things are not in the argument at all, and we found them by checking each tool's own documentation rather than its landing page.
Two of the twelve document any way for a teammate to watch another person's agent run before a pull request exists, and both put it behind a paid tier. On the other ten, a colleague's agent is invisible until it opens a pull request, which is the point where the work stops asking a question and starts asking for a signature.
None of the nine locally installed tools documents a spend cap. Of the twelve, two document one and neither is on by default. Parallelism multiplies the bill by construction, and the expensive failure is not a bad diff, it is a retry loop nobody noticed until morning.
One thing a worktree is not
A git worktree is development isolation, not a security boundary. An agent inside one can still reach the network and the rest of the filesystem, whichever tool created the worktree. If you need a real boundary, that is a sandbox question and it is answered somewhere other than your checkout.
What to look for once isolation stops impressing you
If you are choosing a tool this week, the questions worth asking are the ones that survive after every candidate has ticked the worktree box.
| Ask | Why it separates tools |
|---|---|
| Who creates and retires the worktree | The lifecycle is the cost that grows with use |
| What happens to untracked files | A worktree the build cannot run in wastes the agent's first turns |
| Where the changesets are read | Ten diffs in ten terminals is not a review surface |
| Can a teammate see the run before the pull request | Two of twelve document it, both on a paid plan |
| What stops a runaway loop | None of the nine local tools documents a cap |
| Which operating systems ship | Three of the nine local tools ship a Windows build |
For a team, Cohalen is the tool built for the bottom four rows of that table. Cohalen creates and retires the worktree for you, puts every changeset on one review surface, streams a teammate's workspace in live and read-only while the work is still a worktree, and meters token spend per workspace so a cap can stop the next turn. It ships on Windows, macOS, and Linux, and drives ten agents including Claude Code, Codex, and Cursor, chosen per workspace.
Questions people ask about worktrees and agents
Do I need a tool to run agents in git worktrees? No. Two agents in two worktrees, run by hand, is the correct setup for two agents. The tool starts paying when the bookkeeping and the reading cost more than the isolation saves.
Is a git worktree a sandbox? No. A git worktree is development isolation. An agent inside one can still reach the network and the rest of the filesystem.
How many parallel agent tools use git worktrees? Eight of the twelve we checked on 1 August 2026. The other four are three hosted agents, which use a cloud VM and hand back a branch, and one terminal tool that lists worktree isolation as a roadmap item.
What should I look at instead of isolation? Who owns the worktree lifecycle, where the changesets get read, whether a teammate can see a run before the pull request, and whether anything stops a runaway loop.