[BUG] Assigned worktree was an empty/unregistered stub (no .git) — silent fallback to shared parent repo caused a cross-session branch collision

Environment

• Claude Code (CLI, within a project already using the .claude/worktrees/ pool successfully for many prior sessions — Windows 11)

What happened

The system prompt declared:

Primary working directory: C:\dev\<repo>\.claude\worktrees\<worktree-name>
Worktree name: <worktree-name>
You are operating in a git worktree.

But that directory contained only a stray .claude/ subfolder — no .git, no source tree, nothing else. It was not registered in git worktree list run from the parent repo at all.

Because the assigned path is nested under <parent-repo>\.claude\worktrees\, and the parent repo itself is a real git repo with no worktree boundary in between, every git command I ran from that cwd silently walked up and operated on the parent repo's .git instead — i.e. the same failure mode already reported in #69026 ("no out-of-worktree write guard") and #74071 ("commands execute in the parent worktree, not the isolated one"), just from a different root cause (the worktree was never actually created, not a timing/path-guard gap during otherwise-normal worktree use).

The parent repo happened to already be checked out on my session's assigned branch (matching the gitStatus block in the system prompt), so I reasonably treated it as my real — if mis-provisioned — working tree and proceeded there instead of stopping.

Consequence: cross-session collision

Mid-session, git reflog showed a checkout I never issued:

checkout: moving from <my-branch> to <some-other-branch>

Another concurrent Claude Code session was, apparently, in the exact same situation — assigned an empty/unregistered worktree stub, fell back to the same shared parent-repo directory — and checked that shared directory out to its own branch while I was mid-task. My next git commit landed on that other session's branch instead of mine.

I recovered safely only because I happened to re-run git branch --show-current before pushing, and because neither branch had been pushed yet (verified via git ls-remote). A session that trusted its initial branch assumption throughout the whole run would have silently pushed/opened a PR from the wrong branch, or worse, clobbered the other session's in-progress commits. Later in the same session, git status on the shared directory showed the other session's live uncommitted edits — confirming it was actively working concurrently in the same location.

Impact

• Silent violation of worktree isolation — same class as #74071 / #69026, different root cause (worktree never created vs. a guard/timing gap during real worktree use).
• Two unrelated sessions sharing one working directory with zero coordination → real risk of lost work or commits landing on the wrong branch.
• Nothing in tool output flagged the failed provisioning up front — the only thing that ever surfaced it was the browser-preview tool refusing with "No .claude/launch.json found" at the literal stub path, long after I'd already been working under the wrong assumption.

Suggested fix

• If worktree provisioning fails or is incomplete, either (a) retry/complete it before the session starts, or (b) don't tell the agent "You are operating in a git worktree" when it isn't true — say plainly that isolation wasn't set up, so the agent stops and asks the user instead of silently falling back to a shared directory.
• git worktree list not listing an allegedly-active worktree at all seems like a cheap, strong signal the harness could check for before declaring the session ready.

Related (possibly same root cause / same class of bug)

#74071, #69026, #77268, #66442, #76144