Why Git Worktrees Fail as Isolation Boundaries for AI Coding Agents
Git worktrees are not an isolation boundary for coding agents
I discovered that Git worktrees do not provide true isolation for AI coding agents because they share critical repository state like hooks and configuration. An agent in a worktree can execute code on your host or rewrite your commit identity. My benchmarks show that using a fully isolated clone costs the same in time and disk space, making it the only safe option for running agents in parallel.
A worktree was never a boundary. It is a second working directory attached to one .git, and everything interesting lives in that .git.
- gslepak
Do people not know how to write blogs without AI anymore? I enjoy hearing a human's unique voice and miss hearing it when it's abscent.
- sbysb
Git worktrees are a great isolation boundary for _changes_ (especially making changes in parallel on a single machine), but not behavior. If you are trying to actually run autonomous agents securely you need something that lives outside the harness that actually blocks actions in a way that can't be prompted around.
We use nono [1] for this internally, essentially blocking any actions we don't want agents to be able to do without human approval. Our developers can just run `task claude` or whatever their harness is) and it pre-wraps it with our profile that enforces:
- Filesystem: read/write only the worktree plus dev-tooling dirs (Go, Doppler, Graphite caches, git common dir); explicitly no Docker socket and it can't edit its own Claude settings files (so it can't loosen its own permissions).
- Network: outbound only to an allowlist - Anthropic, Doppler, Go module proxies, our dev environments while still allowing binding local dev-server ports.
- GitHub: read anything in the org, and create/edit PRs and push branches - but it cannot merge, close, review, or comment on PRs, delete branches, touch repo settings/secrets, manage auth, or use raw gh api. Those are all "human-only". GitHub tokens are never exposed to the agent; they're injected by a proxy so it can't read or exfiltrate them.
This is great because it is harness agnostic - any developer can use whatever harness they want as long as they port the nono profile to it, as it will enforce all of the above in a way that […]
- _def
I don't think people use it for isolation, but for what the feature enables in the first place: parallel workstreams
- saltcured
It would be interesting to have a general fix for this in git. Something that more carefully splits the metadata from the working copy, a bit like we used to routinely do with "shadow build trees" with autoconf+make etc.
The parallel trees could have different ownership and access privileges, so that the editable working copy does not require the same filesystem access rights as the metadata tree. The git CLI actions would be performed with the more privileged filesystem role, and it would also have to be audited to make sure it treats all the working copy content as untrusted payload.
- skeledrew
This is quite useful. The title and first paragraph anyway; the rest is fluff. I've actually been trying to solve a problem where I have agents running other agents in worktrees, with the delegated agents contained by jai[0], and the delegating agent would always have to check and reconcile the commits since they get jailed (by design for security). Working on clones instead should resolve that cleanly, as I can relax the .git limitation. I do wish I'd thought it this before.
[0] jai.scs.stanford.edu/