Agent tool `isolation: "worktree"` intermittently moves parent worktree off main

What happens

When spawning a subagent via the Agent tool with isolation: "worktree", the parent session's working tree sometimes ends up checked out to the subagent's feature branch instead of staying on whatever branch it was on (typically main). The isolated worktree at .claude/worktrees/agent-<id>/ is created correctly, but git state in the parent repo drifts as a side effect.

The subagent itself detected and surfaced this in its own return message:

"Parent worktree was on feat/revit-v1.16.0.7. The instructions assumed 'parent session created the branch' — confirmed, but the parent worktree (E:/Developer/Estrelis.ai) had the branch checked out which blocked my worktree from taking it. I moved the parent worktree to main (no uncommitted changes) before running git checkout -B feat/revit-v1.16.0.7 origin/main here. Parent is now on main, my worktree has the branch."

So the subagent had to actively move the parent repo's checkout to free the branch for its own worktree. That's a recovery path, not intended behavior — the isolation contract should be that the parent is untouched by subagent spawns.

Frequency

Third occurrence in one week in my sessions. A prior occurrence (a few weeks back) caused a silent commit-to-main incident that produced ship-time merge conflicts on a feature branch.

Repro shape

1. Long-running Claude Code session, parent on main.
2. Parent session creates a feature branch locally: git checkout -b feat/foo.
3. Parent dispatches Agent with isolation: "worktree", briefing the subagent to work on feat/foo.
4. Subagent completes work, commits, pushes to origin.
5. On return, either:

• Parent's working tree is on feat/foo instead of main, OR
• Subagent reports having manually moved parent back to main as a workaround.

Environment

• Claude Code version: 2.1.113
• Platform: Windows 11 (10.0.26200)
• Shell: bash (git-bash)
• Repo: real project with a long-lived .claude/worktrees/ tree

Relevant git worktree list output at the time of filing:

E:/Developer/Estrelis.ai                                   <sha> [main]
E:/Developer/Estrelis.ai/.claude/worktrees/agent-a2800016  <sha> [feat/revit-plugin-v1.16.0.3-unplaced-spaces] locked
E:/Developer/Estrelis.ai/.claude/worktrees/agent-aa49d376  <sha> [feat/revit-plugin-v1.16.0.2-diaglog-wpf] locked
E:/Developer/Estrelis.ai/.claude/worktrees/agent-ab246b0c  <sha> [feat/revit-plugin-v1.16.0.5-version-stamp] locked

Three locked worktrees from prior sessions — git worktree remove normally fails on these without -f -f. Not sure if long-lived locked worktrees accumulate state that interacts with the isolation logic, but noting it since it's part of my setup.

Ask

• Confirm the isolation contract: the parent's working tree (branch, index, files) should never change as a side effect of an Agent spawn. If my mental model is wrong, happy to hear it.
• If the subagent detecting/recovering from this is intentional, surfacing it as a runtime warning rather than a silent recovery would help. In the incident that caused the merge conflict a few weeks back, the subagent either didn't detect or didn't report, and the drift wasn't noticed until ship time.
• Is there a diagnostic command or log file I should capture next time this happens?

Happy to provide session IDs, exact timestamps, or re-run with verbose logging if that helps.