Session worktree auto-cleaned while the session is still active; git then silently falls through to the parent checkout

Environment

• Claude Code 2.1.198, Windows 11 Pro (10.0.26200), desktop app session
• Session running in a managed worktree under <repo>/.claude/worktrees/<name> (branch claude/<name>)

What happened

1. Session starts normally in its worktree; file edits, tests, and a PR branch all work from there.
2. After the PR merges, the session resets the worktree branch to the remote default branch (git checkout claude/<name> && git reset --hard origin/main) — standard post-squash/merge hygiene so the next PR doesn't stack on merged commits. The worktree is now byte-identical to origin/main with no local changes.
3. Some time later in the SAME still-active session, the worktree has been cleaned: the directory still exists but is completely empty — no .git file, no tracked files — and git worktree list no longer shows it.
4. Because the empty directory still exists and remains the session cwd, subsequent git commands don't fail — git walks up the directory tree, finds the parent checkout's .git (the worktree lives under <repo>/.claude/worktrees/), and silently operates on the user's main checkout. The next git checkout -b created its branch in the main checkout and moved it off main with no error or warning.

Expected

A worktree belonging to a live session should not be cleaned while that session is running — or, if it must be, the cleanup should not leave an empty directory that git path-resolution silently escapes from (removing the directory entirely would at least make the next command fail loudly).

Impact

The failure is silent and compounding: every subsequent git command (checkout, reset, commit) hits the user's main checkout instead of the isolated worktree. In our case a reset --hard could have destroyed uncommitted user changes in the main checkout; we caught it because a directory listing came back empty. The only in-band clues are subtle: git status paths that climb out of the supposed root (e.g. ../../../.gitignore), and git rev-parse --show-toplevel disagreeing with cwd.

Suspected trigger

The timing is consistent with an auto-clean of worktrees that look pristine (identical to origin/main, no local changes) — which is exactly the state the recommended post-merge reset produces mid-session. Not confirmed from our side; the cleanup was not initiated by anything the session ran directly.

Suggested fixes (any of)

• Exempt worktrees whose owning session is still alive from auto-clean.
• On clean, remove the directory itself (loud failure) instead of leaving an empty husk (silent fallthrough).
• Have the harness warn when a session's cwd no longer resolves to its original --show-toplevel.

We've added a local guard (verify git rev-parse --show-toplevel before branch operations), but the silent-fallthrough failure mode seems worth fixing at the source.

🤖 Filed with Claude Code on the affected user's behalf