Session resume does not restore worktree: confusing state mismatch for users

Summary

When a Claude Code session is started inside a git worktree (e.g. one created by an agent with isolation: \"worktree\"), suspending and resuming that session via claude resume does not restore the worktree context. The resumed session runs in whatever directory the shell is currently in, which may be a different branch or the main repo checkout entirely.

Expected behavior

Resuming a session should place the user in the same working directory and git state (branch, worktree path) that was active when the session was suspended, or at minimum warn the user that the filesystem context has changed.

Actual behavior

The session conversation history is restored, but the working directory and branch are determined entirely by the shell environment at resume time. If the original worktree has been cleaned up (which happens automatically for agent-created worktrees), there is no indication that the filesystem context has changed. The user may believe they are operating on the same branch/worktree as before.

Why this matters

• Users who rely on worktrees for isolation (e.g. parallel agent tasks, feature branches) have no guarantee that a resumed session is operating on the intended code
• Claude may read or edit files on the wrong branch without either party realizing it
• The system prompt message "This is a git worktree" remains accurate in wording but misleading in practice — it reflects the session-start context, not the current context

Suggested fix

One or more of:

1. Record the working directory and branch at session start; on resume, warn if the current directory or branch differs
2. For agent-created worktrees, persist the worktree (or a pointer to its branch) so it can be restored or recreated on resume
3. Surface a clear warning at resume time when the git context has changed since the session was created

Environment

Reported by a user during an active Claude Code session on darwin (macOS).