[BUG] Worktree isolation targets the outer repo, not the nested child repo the session started in

Summary

I have an outer git repo with a second, independent repo nested inside it (its own .git, its own remote, gitignored by the outer one). I started a Desktop session in the inner repo and ran a slash-command. The worktree-isolation move that kicked in built the worktree against the outer repo, not the inner one I was working in. The inner-repo work then has nowhere to land until I make a worktree by hand, and a stray worktree and branch get left behind on the outer repo.

The v2.1.203 changelog (see #75452) says the isolation move "operates on the outermost git repository and ignores nested .git/ directories." That keeps it from failing outright, but outermost is the wrong pick when I opened the inner repo on purpose. It quietly overrides the repo I chose.

Environment

Claude Code Desktop 2.1.206, macOS 26.5.2.

Workspace

workspace/            ← outer git repo
  child-repo/         ← nested independent repo (own .git + origin; gitignored by outer)
  .claude/worktrees/

Steps to reproduce

1. Nest child-repo (a full git repo) inside workspace, gitignored by the outer repo.
2. Start a Desktop session in child-repo on its main.
3. Run any slash-command, which triggers the isolation move.
4. The worktree lands at workspace/.claude/worktrees/<name> on branch claude/<command>-<hash>, a worktree of the outer repo. child-repo is never touched. git -C workspace/.claude/worktrees/<name> remote -v confirms the outer origin.

Expected

When the session starts inside child-repo, resolve the worktree against the nearest owning .git (walk up from the session cwd, the way git -C does), not the outermost repo. Or let me pin the target repo, or skip auto-isolation when the session already sits inside a nested repo.

Related

• #73824: sub-repo worktrees in multi-repo workspaces. That one is a rejection/deadlock; this is a silent wrong-repo creation. Its suggested fix (resolve by the nearest owning repo) covers this too.
• #75452: documents the v2.1.203 "outermost wins" behavior this argues against.
• #69026 / #62547 / #60679: same-repo nested-worktree write collisions. Different bug, shared nesting context.