Agent tool: `isolation: worktree` switches parent worktree's branch instead of creating isolated worktree

Summary

When spawning a subagent via the Agent tool with isolation: "worktree" from inside an existing git worktree (not the primary clone), the parent worktree's checked-out branch gets replaced with the subagent's newly-created branch instead of the subagent operating on its own isolated worktree. The side-effect is invisible to the parent session until the next git status / git log, and can make it look like files were reverted when they were actually just on a different branch.

Environment

• Claude Code CLI on Windows 11 Pro 10.0.26200
• Shell: bash (git-bash)
• Parent working directory was a git worktree at C:/Projects/wild-rumpus-WORKTREE2, checked out branch agent/WORKTREE2. The primary clone lives at C:/Projects/Wild Rumpus.
• Model: Claude Opus 4.6 (1M context)

Reproduction (happened twice in one session)

1. Parent session running in a non-primary git worktree (C:/Projects/wild-rumpus-WORKTREE2, branch agent/WORKTREE2).
2. Spawn an Agent tool call with isolation: "worktree", run_in_background: true, and a prompt that tells the subagent to create a new branch off main, make commits, and push.
3. Subagent reports success — creates branch fix/ci-workflow-restore (first repro) / fix/sync-open-orders-test-mocks (second repro), commits, pushes, opens a PR.
4. Parent session continues and eventually runs git status or git log, and discovers:

• Current branch is now the subagent's branch (fix/ci-workflow-restore), not agent/WORKTREE2.
• Working tree reflects that branch's state, so files the parent had committed to agent/WORKTREE2 appear "reverted" (they're on the original branch which still exists locally, just not checked out here).

1. git worktree list still shows only the original worktrees — no new worktree was created for the subagent.

Expected

isolation: "worktree" should:

• Create a fresh worktree under .claude/worktrees/ (or similar) for the subagent,
• Leave the parent worktree's branch and working tree untouched,
• Clean up the new worktree automatically if the subagent made no changes (this part is documented and presumably fine).

Actual

The subagent performs its work directly in the parent's worktree:

• git checkout -b <new-branch> switches the parent worktree to the new branch.
• Subsequent commits land on the new branch in the parent worktree.
• The parent session's in-memory expectation ("I'm still on agent/WORKTREE2") silently diverges from git reality.

Impact

• Confusing: the parent session reports files as "reverted" or "missing" when they're actually on a branch that's no longer checked out in this worktree.
• Risky: if the parent session blindly commits/edits without checking the branch, commits can land on the subagent's branch unintentionally.
• The parent's recovery is simple (git checkout <original-branch>), but only after noticing the issue.

Workaround

Parent session explicitly re-checks git branch --show-current before any commit or push, and runs git checkout <original-branch> if the current branch is unexpected. Not a fix — just defensive.

Session context

This happened in a long-running session working on PR #727 (wild-rumpus repo). The full chain: original parent branch agent/WORKTREE2 → subagent #1 created fix/ci-workflow-restore (repro 1) → subagent #2 created fix/sync-open-orders-test-mocks (repro 2). Both subagents claimed to be running in an isolated worktree in their own reports. Both instead modified the parent worktree's checked-out branch.

If it helps: the primary clone at C:/Projects/Wild Rumpus was also on main and held that worktree, so the subagent couldn't have checked out main there — which may be why it fell back to operating on the parent worktree instead of creating its own. Possibly related to a branch-already-checked-out conflict when trying to worktree add with the same branch name.

Suggested fix ideas

• When isolation: worktree can't create its target worktree (because the branch is checked out elsewhere or a path collision), fail the subagent spawn with a clear error instead of silently falling back to operating on the parent.
• After subagent completion, the parent harness could automatically verify git branch --show-current hasn't changed, and alert the user if it has.