Claude Code's worktree isolation got patched four times between July and August

TL;DR

Symptom Subagents that were supposed to be isolated with isolation: "worktree" could reach into the parent checkout; fixes of the same shape appeared in the official release notes four times

Fixes Four releases, 2.1.203, 2.1.210, 2.1.216, and 2.1.222, each closed off a fix with a different documented scope

Status The official changelog shows no similar fix after 2.1.222 as of August 6

Claude Code subagents isolated with isolation: "worktree" have been fixed four times for reaching into the parent checkout, at least going by what made it into the official release notes between July and August 2026, with the documented scope shifting each time.

When a subagent runs with isolation: "worktree", it works inside its own git worktree. The point is to keep multiple subagents running in parallel from fighting over the same checkout, and to keep one subagent’s changes from leaking into another’s, or into the caller’s main branch. git worktree builds a separate directory that shares the same .git as the main repository, so the possibility of reaching the main checkout through that shared .git was baked in from the start.

What changed across four releases

Here’s what’s in the official GitHub Releases, in order.

Version	Published	What broke
2.1.203	July 7, 21:06 UTC (July 8, 06:06 JST)	Shell commands from a worktree-isolated subagent could sometimes run against the parent checkout
2.1.210	July 14, 23:45 UTC (July 15, 08:45 JST)	A subagent under `isolation: "worktree"` could run git-mutating commands against the parent checkout
2.1.216	July 20 UTC (July 21 JST)	`git -C`, `--git-dir`, `GIT_DIR`, and `GIT_WORK_TREE` could redirect git operations at the shared checkout
2.1.222	August 4, 22:39 UTC (August 5, 07:39 JST)	Worktree-isolated sessions and subagents could run destructive git commands against the parent checkout; the notes state isolation now covers Bash, not just file edits

All four describe the same shape of problem, isolation that’s supposed to hold but doesn’t, and the official release notes use nearly identical wording each time. But going strictly by what the release notes say, the documented scope differs: 2.1.210 covered git-mutating commands in general, 2.1.216 covered redirecting git at another repository with -C or environment variables, and 2.1.222 covered destructive commands run straight through Bash.

Whether this is “the same hole reopening as a regression” or “the scope of isolation just kept expanding to cover more ground” isn’t something I can settle from the public release notes and GitHub Releases text alone. I couldn’t find an implementation PR tied to any of the four fixes as of writing; only CHANGELOG update commits are public, and I couldn’t trace the internal diffs. Rather than calling it four rounds of regression, the more accurate description is that, as documented publicly, the scope shifted across four rounds of fixes.

Why similar problems keep getting reported

Mapped out, the background behind the repeated reports looks like this.

flowchart TD
    A[git worktree add creates an isolated directory] --> B[.git is shared with the main repository]
    B --> C[Normal file edits stay inside the isolated directory]
    B --> D[git -C or GIT_DIR can explicitly redirect the target]
    B --> E[Bash can run git commands directly]
    D --> F[Operations reach the main worktree through the shared .git]
    E --> F
    F --> G[What was meant to be isolated writes to, or destroys, the parent checkout]

git worktree is designed so multiple working directories share the same .git object database and refs. A different directory on the filesystem doesn’t block -C, GIT_DIR/GIT_WORK_TREE environment variables, or git commands run directly through Bash from reaching that shared .git. How each of those operations got blocked isn’t something the public record shows. The 2.1.222 notes state that isolation covers both file edits and Bash after the fix, but they don’t show how the implementation was split before it.

What release-note cross-checking can show

The only way to verify isolation: "worktree" is to point a subagent at a real, working git repository and have it attempt destructive operations to see whether isolation holds. That can wreck the main checkout along the way. A throwaway repository would contain it, but each of the four fixes needs its own reproduction setup, so this piece stays scoped to cross-checking the official release notes.

If you’re using worktree isolation, update Claude Code to 2.1.222 or later first. If you have a workflow where an isolation: "worktree" subagent runs destructive operations, verify isolation actually holds against a harmless repository even after updating. Being worktree-isolated is no safety guarantee on its own, so for repositories you genuinely don’t want touched, layer on separate permission settings or review for the subagent.

I’ve tracked Claude Code bugs here before: the false report that Claude Code was running git reset --hard every 10 minutes on the destructive-git side, and the “court” bug where tool calls leak as text instead of running on the tool-call side.