chopshopr

Isolation question

If coding agents can edit everything, why do serious builders still isolate one task per worktree?

Because the worktree is not Git nerd cosplay. It is the filesystem address of responsibility when an agent is finally allowed to change something real.

By Chopshopr 10 min read
Opinions If coding agents can edit everything, why do serious builders still isolate one task per worktree?
Contact Chopshopr

This is loser-interesting because it makes the serious builder look like a clerk while everyone else is showing autonomous demos. But the current primary sources point the same way. Git says linked worktrees share repository history while keeping per-worktree files such as HEAD and index. MCP says tools are model-controlled, but there should still be a human in the loop with clear indicators and confirmation prompts. My inference from those sources is blunt: once an agent can mutate a repo, the unit of safety is not just the tool. It is the lane.

The thesis:

Serious builders isolate one repo-changing task per worktree because correctness is not enough. They need a visible owner for the side effect, a clean branch or detached-HEAD handle, and a ship gate that a second operator can inspect without reconstructing the whole mess.

Git already treats a worktree like a bounded lane

The official git worktree documentation describes the feature plainly: one repository can support multiple working trees, which lets you check out more than one branch at a time. It also says a linked worktree shares repository data while keeping per-worktree files such as HEAD and index separate.

That is already the shape of a responsibility boundary. One lane can belong to the hot fix. Another can belong to the blog launch. Another can stay detached for risky testing that should not quietly attach itself to a shared branch name.

The same doc says git worktree add refuses to check out a branch in a new worktree if that branch is already checked out somewhere else unless you force it. Git is not being precious there. It is protecting you from ambiguous ownership. The list output also surfaces whether each worktree is on a branch or in detached HEAD. The system wants the active lane to be legible.

Then git config adds another clue: there is a distinct worktree config scope via config.worktree. Even configuration can be lane-specific. Git is telling you, in boring plumbing language, that multiple futures should not all blur together in one mutable directory.

Working style Feels fast in the moment What breaks under pressure
Many tasks in one dirty directory No setup overhead Ownership, rollback, and blocker reporting blur together
One task per linked worktree One extra path to create Branch, dirty files, and proof gate stay attributable
Detached test worktree Easy experimentation Safe until someone forgets it is intentionally branchless
Forced branch reuse across lanes Looks convenient Turns every later summary into a guessing exercise

Model-controlled tools make the lane problem sharper, not smaller

The MCP tools specification says tools are designed to be model-controlled. It also says there should always be a human in the loop with the ability to deny tool invocations, and that applications should show clear indicators and confirmation prompts.

That requirement is deeper than a dialog box. A human cannot review a repo-changing action honestly if the action lands in a murky workspace that already contains two unrelated edits, an abandoned experiment, and a stale deploy tweak. The approval surface becomes under-specified. "Apply the patch" is not enough. The reviewer needs to know which path, which branch or HEAD, which dirty files, and which truth gate own the task.

This is why isolated worktrees pair naturally with agent tooling. The tool call says what is about to happen. The worktree says where that action will live afterward. One without the other still leaves too much ambient ambiguity.

The embarrassing part is that isolation feels slower until a run slips

Nobody brags onstage about creating another directory. But the cost of skipping that step shows up later in the most humiliating places: a blocker report that cannot name the failing command cleanly, a mixed diff that no longer has a single owner, a deploy fix lost inside unrelated edits, or a second operator who has to ask what was actually touched.

The worktree does not remove all failure. It makes failure classifiable. Instead of "the repo got weird," you can say: this task lived in this path, on this branch or detached HEAD, with these task-owned files, this failing command, and this next repair step. That is the difference between a dramatic story and a handoff packet.

In practice, that classification speed matters more than the 20 seconds you saved by skipping setup. The serious operator is optimizing for clean recovery, not theatrical velocity.

What this looks like in Chopshopr's world

Chopshopr lives exactly in the zone where this matters: local-first agents, MCP servers, on-device inference, NemoClaw host operations, public routes, and visible ship gates. The temptation in that world is to treat locality as safety. It is not. Local power without lane clarity is just private confusion.

That is why the repo keeps pushing toward literal handles: bun run worktree:check before editing, one task-owned branch or deliberate detached lane, bun run build before claim of completion, and a deploy path that ends in a cache-busted live verification when the public site changed. The worktree is where those later receipts attach.

The same lesson applies beyond code. A public article route needs one owner. A local inference lane needs one default model. A host-ops tool needs one bounded surface. The deeper pattern is not "use worktrees because Git said so." It is "give each consequential line of action one legible place to stand."

The practical build pattern

  • Create a linked or deliberate detached worktree before the first repo-changing tool call.
  • Make the active lane explicit: path, branch or HEAD, and task purpose.
  • Keep task-owned edits separate enough that a blocker report can name them without apology.
  • Run one truth gate such as bun run build from that lane before claiming progress.
  • When the task changes a public surface, attach the lane to a route, deploy, and live proof.

If a coding agent wants real authority, ask one rude question before you let the run widen: why does this task not have its own worktree yet?

Sources