`-w` worktree not preserved across `--resume`; worktree directory created but never git-registered

What happened

Started a session with claude -w <worktree-name> in a git repo, did
some work, ran /exit, then resumed moments later (no reboot, no
meaningful delay) with:

claude --resume 75a2ab1b-fee7-44f4-b02f-7f0d54b3ec1f

A second, separate Claude Code session was also active in the same repo
around this time, working directly on main (never given a -w flag).
That session was independently /exited and resumed the same way
(claude --resume <its-own-session-id>) at roughly the same time. It's
unclear whether either session had made any file edits yet at the point
of its exit/resume — possibly one had, possibly neither — so it's not
established whether the two resumes interacted or are relevant to each
other at all; noting it in case it's a useful data point.

Expected

The resumed session continues operating inside the same isolated worktree
created by -w.

Actual

The resumed session was operating directly in the main repo checkout on
main, not any worktree. A leftover directory
.claude/worktrees/<name>/ existed and was visible to the resumed
session (found via a find/grep early in the session), but it was
not a git-registered worktree:

• git worktree list never showed it
• no corresponding entry existed under .git/worktrees/

That directory was gone entirely by later in the session, with zero
trace in .git/worktrees/ (not even a stale admin dir left for
git worktree prune to clean up).

Impact

A second, separate Claude Code session was concurrently working directly
on main in the same repo. Because the first session's -w isolation
never actually took effect, both sessions' uncommitted edits landed in
the same shared working tree — real risk of one session's edits
clobbering the other's, only avoided here because the touched
line-ranges happened not to overlap. Had to manually reconstruct
isolation after the fact with git worktree add + hand-splitting the
already-mixed diff.

Environment

• Claude Code 2.1.220
• macOS (Darwin 25.5.0)
• Plain git repo, .claude/worktrees/ already present in .gitignore

(suggesting that path is the intended convention for -w targets)

Repro (best guess — steps as reported by the user, not independently

verified command-by-command)

1. claude -w <name> in a git repo
2. Do some work
3. /exit
4. claude --resume <session-id> moments later — no reboot, no delay
5. Observe: session operates on the main checkout; the named worktree

never appears in git worktree list at any point.

No host reboot was involved at any point in this sequence.

Related issues

This looks like the same general worktree+resume problem area as several
other open reports, though not an exact duplicate of any I found —
in this case the worktree was never git-registered at all (not even
present in .git/worktrees/), rather than resume mis-targeting an
existing, properly-registered worktree. Also, unlike #84923, no reboot
was involved:

• #80014 — resumed session inside a git worktree acts as the root worktree (commits land on root's branch)
• #84209 — session history orphaned when session ends inside EnterWorktree worktree
• #84923 — background agent resumed after host reboot gets permanently pinned inside a worktree
• #85234 — isolation-worktree guard compares paths case-sensitively on Windows, breaking resume