Git Worktrees: Giving Each Coding Agent Its Own Sandbox So They Stop Overwriting Each Other

When you run more than one coding agent at the same time inside a single repo, they fight over the same files. The video shows a fix: give every agent its own git worktree so each one edits an isolated copy of the codebase. On screen is a VS Code window running Claude Code v2.1.178 (Opus 4.8, signed in as Cole through the Claude API) inside a project called agent-control-plane. A single typed prompt kicks off four agents to fix four GitHub issues at once, each in its own worktree, then validates the results. The overlay frames the idea as "Loop engineering in practice."

The problem with parallel agents in one repo

A git worktree lets you check out multiple branches of the same repository into separate directories at the same time, all backed by one .git store. Without that separation, two agents working in the same directory write to the same files, and one agent's edits clobber the other's. The narrator puts it plainly: if many agents are handling tasks in a loop, they have to run in isolation so they are not stepping on each other's toes. He credits Boris (Anthropic's Boris Cherny, who works on Claude Code) for making the same point. The payoff he names is throughput: isolated workspaces are how you scale output with AI coding assistants instead of bottlenecking everything through one shared directory.

One prompt, four agents, four worktrees

The terminal holds a single instruction that drives the whole run. The text, highlighted as it gets selected and copied on screen, reads:

Use Archon to fix GitHub issues #1, #2, #3, and #4 in parallel - one workflow per issue, each in its own worktree. After all four finish, check that a PR was created for each. If so, run the Archon PR-validate workflow to review each of the four PRs in parallel, then report back to me once everything is done.

A few things to pull out of that. The work is split one workflow per issue, and the prompt explicitly pins each workflow to its own worktree, which is the isolation the narrator is arguing for. The tool doing the dispatching is called Archon, with a named PR-validate workflow for the review step. Claude Code is running in bypass-permissions mode, shown at the bottom of the terminal as "bypass permissions on (shift+tab to cycle)," so the agents can act without stopping to ask for approval on each step. The right-hand panel shows two terminal tabs both labeled "claude," consistent with more than one Claude session running side by side.

The loop: fix, validate, review

The narrator describes the run as a loop with three stages rather than a single one-shot action. First, four workflows go out to handle the GitHub issues. Second, the system validates that the work actually landed, meaning it checks that a pull request was really created for each issue rather than assuming success. Third, it runs four more workflows to perform a code review on each PR, again in parallel. He also points out where a person fits in: this is where you can come in with a human in the loop, reviewing or intervening before things merge. The full shape is handle the issues, confirm the PRs exist, then review each PR, and only then report back.

Why the validation step matters

The interesting design choice is the explicit check between fixing and reviewing. The prompt does not just fire off four fixes and trust them. It says check that a PR was created for each, and only run the review workflow if so. That guard keeps the loop from reviewing work that never actually got committed or opened as a PR, which is a common failure mode when you let agents run unattended. Pairing isolated worktrees with a verification gate is what lets one operator dispatch a batch of parallel agents and still get a trustworthy result at the end.

Key Takeaways

• Git worktrees give each coding agent an isolated checkout of the same repo, so parallel agents stop overwriting each other's edits.
• Isolation is the thing that lets you scale agent output; without it, everything funnels through one shared working directory.
• A single prompt can dispatch multiple agents at once, with the instruction explicitly assigning one worktree per task.
• Treat the run as a loop: fix the issues, verify a PR was actually created for each, then review the PRs, then report back.
• Build in a validation gate so the review step only runs against work that really landed, not assumed successes.
• Keep a human in the loop at the review stage even when agents run with permissions bypassed for speed.