Chip/spawn_task session start runs `git checkout -b claude/<name>` in the PARENT repo when the created worktree dir is not a real worktree — silently flips the shared main checkout for ALL parallel sessions (Windows 11)

Summary

On Claude Code Desktop (Windows 11), starting a chip / spawn_task session creates .claude/worktrees/<name> — but the directory frequently is not a real git worktree (no .git link file; in one affected repo, 9 of 10 such directories had none). Git commands issued from the new session therefore resolve up to the parent repository, and the harness then runs git checkout -b claude/<name> there.

Result: the one shared main checkout switches its branch. Every parallel session working in that repository — plus the running dev server — is silently moved onto claude/<name>. No error, no warning; the flip happens at harness level before the first agent instruction executes, so prompt-level guardrails cannot prevent it.

Forensic evidence (git reflog of the parent repo)

21:07  checkout: moving from main to claude/cool-williamson-7441df   # chip start
22:53  checkout: moving from claude/cool-williamson-7441df to main   # manual recovery → 1h46 of drift
23:14  checkout: moving from main to claude/brave-kowalevski-dd9b1c  # next chip start
23:23  checkout: moving from claude/brave-kowalevski-dd9b1c to main

The operator reports ~10 occurrences over a few weeks. Directory inspection at the time: 10 dirs under .claude/worktrees/, only 1 (manually created via git worktree add) was a registered worktree with a .git link.

Environment

• Claude Code Desktop on Windows 11 (observed repeatedly; app current as of the incidents), CLI currently 2.1.214
• Heavy multi-session use: ~11–12 parallel sessions sharing one working directory (no per-session worktrees, by policy)

Impact

• All parallel agent sessions suddenly operate on the wrong branch; commits made during the drift window land on claude/<name> and strand there
• Running dev server serves the wrong branch
• Recovery is manual (git checkout main), and only after someone notices

Relationship to #78980

Likely the same root cause as #78980 (a dir under .claude/worktrees/ without a .git entry silently resolves to the parent repo) — but a distinct and higher-blast-radius symptom: there, the agent's commit lands on the parent's branch; here, the harness itself flips the parent checkout's branch at spawn time, affecting every concurrent session.

Suggested fix

Before any branch operation at spawn, assert the created directory is actually isolated:

[ "$(git -C <dir> rev-parse --show-toplevel)" = "<dir>" ]        # resolves to itself
[ "$(git -C <dir> rev-parse --git-dir)" != "$(git -C <dir> rev-parse --git-common-dir)" ]

If either check fails: fail the spawn loudly — never run git checkout -b when the resolved toplevel is the parent repository.

Local mitigations (for other affected users)

• post-checkout hook that screams when the main checkout lands on any non-main branch
• pre-commit hook that hard-blocks commits when the shared main checkout is on a non-main branch (linked worktrees exempt via git-dir != git-common-dir)

These make the flip loud and consequence-free, but the flip itself still happens.