The 'isolated worktree' in your AI coding setup is not a boundary

A coding agent in a "linked" git worktree can plant a post-commit hook that runs the next time you commit in your real repository, as you, with your shell. The same agent can rewrite the user.email on the commits you are about to push, or pop another agent's stash entries into its own tree. The analysis at Fletch walks the path with paste-and-run reproductions and lays out the underlying reason: a worktree is a second checkout of the same repository, not a copy of it.

Per-worktree state is a short list. The files git keeps per worktree are HEAD, the index, ORIG_HEAD, and a handful of bisect and rebase files. Everything else, including objects, refs, config, stash, and the hooks directory, is common state shared with the main repository. Inside a linked worktree, the .git "directory" is a one-line file pointing back to the original repo via --git-common-dir, so the hooks directory the agent can write to is the host's hooks directory. That is what the "isolated worktree" pitch is actually buying you: a separate working tree on disk, which keeps parallel agents from clobbering each other's uncommitted edits. It is not a sandbox.

This is a wrong mental model that tool descriptions and advice threads keep repeating. "Isolated" in this context usually just means "second checkout." The boundary the worktree offers is against file-level collisions between agents working in the same repository, not against an agent that shares the host's .git. A coding agent that can write to .git/hooks can run code on the host with the host's credentials, on the host's machine, in the host's shell. That is the same trust boundary the rest of the developer's machine already has, not a new one.

The cheap fix is a fresh clone. The post retracts an earlier claim that proper isolation, meaning a real clone rather than a worktree, was expensive. Measured at the command line, a git clone to a new local directory takes about a second on a warm filesystem, the same order of magnitude as git worktree add. The cost of a real boundary is the cost of a linked worktree. The author measured this directly, then walked back the earlier framing.

The framing change is also vendor-friendly. Replacing "isolated worktree" in tool descriptions with "separate working tree, shared repository state" would line marketing language up with how git itself documents the feature. It names the boundary and the gap in one phrase, and it gives users a checklist item they can verify by running git rev-parse --git-common-dir inside the worktree. The same verification flags any tool wrapper that mounts the host's .git into a sandbox.

For someone running parallel coding agents today, the practical checklist is short. Audit .git/hooks the way you would audit any shared writable directory: it is, in practice, an unauthenticated execution surface for any process that can write to it. If a tool gives you a worktree per agent, treat the worktree as a working-tree convenience, not as isolation. For real isolation between agents, give each one a fresh clone (or a fresh local bare repo plus working tree pair), and audit which directories the agent can actually reach. The shared-.git problem disappears the moment the agent is not in the same repository at all.

Two things to watch. First, the same execution surface shows up anywhere an agent can reach .git/hooks, .git/config, or .git/info, including some "agent-friendly" wrappers that mount the host's .git into a sandbox. Second, "isolated" is doing a lot of work in parallel-coding-tool marketing. The two state lists, per-worktree state and shared state, are what "isolated" should distinguish. Tool authors have not done that yet, so "isolated worktree" reads as "second checkout," and a real clone is the only off-the-shelf boundary at the same cost.