[Bug] --resume flag loses context when --worktree option was used in original session

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/27883
2. https://github.com/anthropics/claude-code/issues/28314
3. https://github.com/anthropics/claude-code/issues/5768

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is a specific and painful failure mode — the --resume + --worktree combination should preserve the full session context, but the worktree checkout appears to silently break the session linkage without any warning.

The underlying issue here is that session identity and git state aren't being tracked as a unified object. If the session ID doesn't carry a reference to the worktree's git state at the time of creation, resume has no reliable anchor to restore from.

I've been using Mantra (mantra.gonewx.com) as a persistent layer for exactly this pattern — it maintains a session timeline that's anchored to git commits rather than just session IDs, so when a --resume drops context after a worktree switch, I can see exactly what the session had at each git state and manually restore the right checkpoint. Not a fix for the underlying bug, but a workable mitigation until this is resolved natively.

Found 3 possible duplicate issues: 1. [[BUG] --resume flag fails to find session when run from a different directory than the original session #27883](https://github.com/anthropics/claude-code/issues/27883) 2. Sessions in worktrees cannot be resumed after worktree cleanup #28314 3. [[BUG] Resuming sessions only works from the directory in which they were started #5768](https://github.com/anthropics/claude-code/issues/5768)

None of those are duplicates.

The first and third are about running the --resume from a different directory, but this worktree problem occurs when you're in the _same_ directory as when you started that session with claude --worktree — even directly after quitting the session (e.g. to brew upgrade claude-code and intending to jump right back in...)

The second is “after worktree cleanup” but this fails even if you kept the worktree.

Seems like you need the worktree path in the invocation, claude --worktree /path/to/worktree --resume $UUID, for the resume to work.

you can get around this by running claude --resume, then, in the interactive session picker, toggling "all worktrees" by pressing Ctrl w. This is not a great solution though - agreed that emiting the --worktree flag in the resume command would be much better.

Confirmed on v2.2.16 (macOS, claude-opus-4-6 1M context). Additional finding:

--worktree <name> --resume <id> works even when the worktree has already been cleaned up. It recreates the worktree and resumes the session with full context intact.

My case: a plan-only session in a worktree (no code changes, only file reads and writing to ~/.claude/plans/). After killing the session, the worktree was auto-deleted (no commits). The printed claude --resume <id> failed, but claude --worktree <name> --resume <id> successfully recreated the worktree and resumed.

The fix should be straightforward — when a session was started with --worktree, include it in the printed resume command:

Resume this session with:
claude --worktree <name> --resume <id>

This was fixed in v2.1.101 — The exit hint now includes --worktree <name> in the suggested --resume command when the session was started in a worktree. If you're still seeing this in the latest version, please comment with your version and repro and we'll reopen.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.