claude --resume fails silently for worktree conversations when run from main repo

[premiumFrye]

Summary

claude --resume <id> silently fails with "No conversation found" when the conversation occurred inside a git worktree and the command is run from the main repository root. There is no indication that the conversation exists or where to look for it.

Steps to Reproduce

1. Start a Claude Code session inside a git worktree (e.g. /repo/.claude/worktrees/my-worktree/)
2. Do some work — the conversation is stored in ~/.claude/projects/-<path-to-worktree>/
3. Exit the session
4. From the main repo root (/repo/), attempt to resume: claude --resume <conversation-id>
5. Result: No conversation found with session ID: <id>

Expected Behavior

One of:

• --resume finds conversations across all worktrees for the same repo, or
• The error message indicates where conversations for that ID are stored (e.g. "found in worktree project — run from /repo/.claude/worktrees/my-worktree/"), or
• The docs clearly explain that --resume is scoped to the current working directory's project path

Actual Behavior

Silent failure: No conversation found with session ID: <id>. No hint that the conversation is in a different project path, no suggestion to cd into the worktree.

Workaround

cd /repo/.claude/worktrees/<worktree-name>
claude --resume <conversation-id>

Conversation files for worktree sessions live in:
~/.claude/projects/-<encoded-worktree-path>/

Why This Is Confusing

• --resume accepts the ID without error — it just says "not found", implying the ID is wrong
• The conversation ID comes from the same ~/.claude/projects/ tree, so users assume it's globally addressable
• There's no documentation explaining that --resume scope is tied to cwd
• Worktrees are commonly used for parallel/agent work where resuming a dropped session is especially important

Environment

• Claude Code CLI on WSL2 (Ubuntu on Windows)
• Git worktrees created both manually (.worktrees/) and by agent tooling (.claude/worktrees/)

[github-actions]

Found 3 possible duplicate issues:

1. [Bug] --resume flag loses context when --worktree option was used in original session #28769
2. --resume shows no sessions when cwd is a bare repo root with worktrees #48110
3. [BUG] /resume finds no conversations when submodule has an active secondary worktree #45179

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

[0xbrainkid]

Silent failure with "No conversation found" when the conversation is in a worktree project path is a session identity scope mismatch — the session exists, but --resume is looking in the wrong project path because it scopes by CWD rather than by session ID globally.

From a session identity perspective, a conversation ID is a globally unique identifier for a specific session. That session happened in a specific worktree context. The --resume <id> command should be able to locate any session by ID regardless of where the user is running it from — the ID itself should be the lookup key, not the combination of ID + current project path.

The three fix options you proposed in priority order:

1. Resume finds conversations across all worktrees for the same repo (best UX). A session ID lookup should search all project paths that are part of the same git repo — main repo and all its worktrees. The relationship git worktree list provides is the link that makes this possible.

2. Helpful error when the session exists elsewhere. If the lookup fails in the current project path but would succeed from a different project path (worktree or main repo), the error should say so: "Session <id> not found in current project. Found in worktree project at /repo/.claude/worktrees/my-worktree/. Run from there to resume."

3. Documentation. If neither fix is implemented immediately, at minimum document that --resume is scoped to the current working directory's project path so users know where to look.

The silent failure is the most frustrating outcome — users lose trust in --resume reliability when it returns "not found" for sessions they know exist.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[github-actions]

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.