Worktree guard keeps enforcing a deleted worktree after the session is rebound to the origin repo

Environment

• Claude Code desktop app 2.16120.0 (macOS, Darwin 25.5.0); claude-code 2.1.284; agent SDK 0.3.284
• Session started in an app-managed git worktree (<repo>/.claude/worktrees/<slug>), left dormant ~5 weeks, then resumed

Steps to reproduce

1. Start a desktop-app session that runs in an app-created git worktree.
2. Leave the session dormant long enough that the app cleans up the (unchanged) worktree.
3. Resume the session. The harness handles this correctly: the shell reports the deleted working directory and recovers, a system notice states the session "now operates on the origin repository at <repo>", and an environment update confirms the primary working directory is the origin repo and "no longer a git worktree".
4. Attempt an Edit or Write to a file in the origin repo.

Observed

Every Edit/Write is blocked by the built-in worktree guard:

PreToolUse:Edit hook error: This session is running in an isolated git worktree at <repo>/.claude/worktrees/<slug>, but <repo>/claude.md is in the base repo checkout. Edits there do not land on this session's branch and may corrupt the user's primary working copy. Use the worktree path instead: <repo>/.claude/worktrees/<slug>/claude.md

The suggested path no longer exists — the app itself deleted that worktree. The guard appears to consult a session→worktree mapping that is not invalidated when the worktree is removed, even though the rest of the harness has already rebound the session (cwd recovery, environment updates, project CLAUDE.md re-read from the origin checkout). The session's shell environment carries no worktree-related variable, so the stale binding lives in the app's internal session state.

Additional notes:

• This is not a user-configured hook: there are no PreToolUse entries in global, project, or managed settings, and the message text appears nowhere on disk.
• Bash file writes are not intercepted, so the guard can be bypassed — which undermines its protective purpose while it blocks the legitimate tool path.
• The guard also fires with a separate message branch for files under the base repo's shared .claude/ directory; that branch has the same staleness problem.

Expected

When the session's worktree no longer exists and the harness has rebound the session to the origin checkout, the guard should either stand down (ideally with a one-line warning naming the dead worktree) or emit an error that accurately describes the situation — never redirect writes to a deleted path.

Report drafted by Claude Code from inside the affected session, at the user's request.