Worktree isolation guard mis-binds multiple subagents from one terminal to a single worktree slot (freezes Edit/Write/git)

Summary

Multiple Claude Code subagents spawned from the same terminal session are being mis-bound to a SINGLE worktree entry in the PreToolUse worktree-isolation guard's session→worktree registry. When subagent A runs EnterWorktree, the guard registers the shared terminal pid → A's worktree. Subagents B/C spawned afterward (sharing the same terminal) inherit that binding: their Edit/Write/git calls targeting their OWN worktrees (or the shared checkout) are refused with "This session is isolated in the worktree .../e-ab-designgate" — naming A's tree, not theirs.

Impact (observed in one 14-hour session)

• 3 of ~10 parallel subagents were frozen mid-task (Edit/Write/git all refused), each for 20-40 minutes.
• One subagent's fixes had to be materialized as a /tmp patch and applied by the lead (double-handling).
• The Commander session itself inherited the binding after later spawns, blocking main-checkout git operations (commits, merges) until each worktree holder exited.
• A stale binding persisted even after the bound worktree directory was removed by the integrator (getcwd errors on every command).

Reproduction

1. From one CC session, spawn 2+ subagents (Agent tool) where the first calls EnterWorktree.
2. Subagents attempt Edit/Write/git on their own task worktrees or the shared checkout.
3. Observe refusals citing the FIRST subagent's worktree path regardless of which tree the caller targets.

Expected behavior

• The session→worktree registry should key on the SUBAGENT's own session id (or per-spawn identity), not the shared terminal pid — each spawned subagent gets its own binding slot.
• At minimum: a binding to a worktree that no longer matches the caller's actual cwd/session should self-heal or fall back to read-only-allowed instead of freezing all write paths.

Workaround used

Lead exited its own worktree binding (releasing the shared slot), then the frozen subagent retried successfully. But the collision recurs on every multi-subagent batch, and the Commander's own git access flaps depending on which subagent entered a worktree last.

Environment

• Claude Code 2.1.263, Linux
• Multi-subagent parallel batches (5-10 concurrent Agent-tool spawns) from one terminal