Session becomes inaccessible after worktree auto-cleanup

Bug Description

When Claude Code automatically cleans up a worktree directory (~/.claude/worktrees/{name}/), the associated session becomes inaccessible — even though all session data is fully preserved on disk.

Environment

• OS: macOS (Apple Silicon — M1 / iMac)
• Claude Code: Latest (VSCode extension + CLI)
• Project size: Large monorepo

Steps to Reproduce

1. Start a session → Claude Code auto-creates a worktree under ~/.claude/worktrees/{random-name}/
2. Leave the session (e.g., to reference a previous session log)
3. Worktree gets auto-cleaned (deleted) because no file changes were detected
4. Attempt to resume the session → fails

Expected Behavior

Session should remain accessible regardless of worktree lifecycle. Possible approaches:

• Fallback: Re-bind session path to the main repo when worktree is gone
• Re-create: Regenerate the worktree on session resume
• Decouple: Store session state independently from worktree path

Actual Behavior

Session cannot be resumed. The session path references a deleted worktree directory, and there is no fallback mechanism.

Evidence

Session data is fully intact:

# Session index — preserved
~/.claude/projects/-Users-...-monk-project-/sessions-index.json

# Session conversation — preserved (.jsonl)
~/.claude/projects/-Users-...-monk-project-/{sessionId}.jsonl

# Worktree directory — DELETED (auto-cleanup)
~/.claude/worktrees/{name}/ → gone

The data is persistent, but the entry point is broken.

Root Cause Analysis

Session context and git worktree (filesystem) are tightly coupled. These two have independent lifecycles and should be managed separately:

• Git worktree: Temporary, disposable (code isolation purpose)
• Session context: Should persist across worktree lifecycle changes

Impact

• Users who carefully manage session continuity lose access to sessions with full conversation history
• Particularly impactful for long-running, context-heavy projects where session context is critical
• The workaround (re-explaining context in a new session) is costly in both time and tokens

Additional Context

• Confirmed that sessions-index.json retains all session metadata (sessionId, firstPrompt, messageCount, timestamps, gitBranch)
• Multiple orphaned worktrees were also observed (not cleaned up), suggesting the cleanup logic itself is inconsistent