Agent isolation (worktrees)

What it is

Agent isolation means each task gets its own working copy of the code, called a sandbox, rather than every agent editing the same checkout at once. A git worktree is the mechanism under the hood: a separate directory tied to its own branch, so one task's half-finished edit can't leak into another task's run. The sandbox lasts for the task's whole life, across however many sessions it takes, and is cleaned up once the task reaches a done state.

Why it matters to you

If you're running more than one agent at a time, this is what stops them from stepping on each other, one agent's incomplete edit corrupting the file another agent is reading. It's also what limits the blast radius: a task's sandbox reaches only what it's given, and nothing else on your machine. Without it, running agents concurrently on the same checkout is a recipe for one task quietly undoing another's work.

How it works in CodeHerder

CodeHerder creates a durable per-task sandbox. It tracks that sandbox and cleans it up once the task is done, rather than leaving that to whoever's running the terminal. What an agent running on your device can actually reach, and the ways to tighten that further, such as a dedicated OS user or a per-stage container, are covered in the agent isolation doc, including the trade-offs of each option.

• Isolating agent runs →

What people get wrong

The word "sandbox" invites a mix-up: in the security sense it can suggest a toy environment, so people sometimes assume isolating an agent means it can't touch anything real. Here it means each task gets its own working copy of your actual repository, still capable of a real commit, just kept separate from every other task running at the same time. The isolation buys concurrency safety; it says nothing about what a finished change can eventually reach once it's reviewed and merged. Tightening what a session can reach beyond its own sandbox is a separate, additional layer, one this setting alone doesn't provide.