[BUG] Resuming sessions only works from the directory in which they were started

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/4843
2. https://github.com/anthropics/claude-code/issues/1977
3. https://github.com/anthropics/claude-code/issues/4926

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

Some of the issues marked above are related but not duplicates. This issue focuses specifically on the --session-id UUID and --resume UUID pair of arguments which should be independent of the current working directory. This does not apply to --continue to which probably should continue the last conversation that took place in the current working directory.

A simple solution to this problem which would require very few changes would be to search all of /home/USER/.claude/projects/ for a conversation when the UUID is explicitly given.

+1

+1. Our use case is in the sdk - we duplicate the root directory structure on every iteration to save history, but want to resume in the new directory

I just got bit by this one as well.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This is still an issue.

I can also confirm that this is still an issue. The same issue is _also_ present in the Claude Agent SDK v0.1.62.

Just hit another variant of this issue. When using the resume menu (claude --resume) with A to show all projects, selecting a session from a different directory generates the wrong cd command.

What happened:

Session was created in /home/artur/Repositories (confirmed in ~/.claude/history.jsonl):
{"project":"/home/artur/Repositories","sessionId":"XXX"}

But when resuming from /home/artur/Repositories/tinygrad, the menu showed:
This conversation is from a different directory.

To resume, run:
cd /home/artur/Repositories/tinygrad && claude --resume XXX

Running that command: No conversation found with session ID: XXX

The resume menu should read the project field from the history file instead of using pwd.

Environment: Claude Code v2.0.69, Linux

Just ran into this myself. Notably this is tagged "platform:linux" but it also shows up on windows, and I'd assume macos as well. Adding another use case that reinforces why this matters.

The launch directory determines Claude Code's security sandbox scope. If you start Claude from a parent directory, create a new project subdirectory during the session, and want to continue working with a tighter sandbox, you're stuck - you can't resume the session from the subdirectory.

This is particularly relevant when a session evolves from exploration/scaffolding (broad access needed) into focused development (narrower access preferred). Currently you have to choose between an overly permissive sandbox or losing your session context.

This also affects --resume <session-name> (not just UUIDs). After using /rename my-session, running claude --resume my-session from a different directory fails with "No conversations found to resume" - the name lookup is scoped to the current project directory's session store.

Manually copying the session .jsonl file and its corresponding directory from ~/.claude/projects/<old-path>/ to ~/.claude/projects/<new-path>/ does appear to work. The session loads and functions correctly from the new location. This suggests the fix could be straightforward - the session data itself isn't path-dependent, just the lookup mechanism.

@jeff-hiner yes, this also happens on macOS. I can confirm.

Additional reproduction case: /resume suggests the wrong directory

I encountered a variant of this bug where the /resume command actively provides an incorrect directory suggestion.

Environment:

• Claude Code: 2.1.14
• OS: Fedora 42 (kernel 6.17.9)
• Shell: bash

Scenario:

1. Launched Claude from /home/user
2. During the session, worked on files in /opt/repos/myproject
3. Session metadata recorded projectPath: "/opt/repos/myproject"
4. Session file stored in ~/.claude/projects/-home-user/<session-id>.jsonl

The bug:
When running /resume, Claude suggested:
cd /opt/repos/myproject && claude --resume <session-id>

This fails because the session is stored under -home-user, not -opt-repos-myproject. The suggestion uses projectPath (where I worked) instead of the actual storage location (where I launched Claude).

Workaround: Resume from the original launch directory:
cd /home/user && claude --resume <session-id>

+1

I was working deeply in one repository and Claude+VS Code session, but a part of the roadmap for the feature was to move it to another repo. When done I wanted claude to change its working directory, exit and then resume from the other folder in another VS Code session.

still a problem today, really weird this is not prioritised, it prevents Claude CLI from actually being the single source of truth across several applications (as they all come in with their own folder structure)

Seems like a no-brainer to me to allow somebody to search past sessions across all projects in order to figure out which one to resume.

I don't even care which working directory they resume in. I just want the ability to find that one random session that I start every week in the wrong place and pick up from where I left off.

Especially annoying/damaging when you start a new project from a different directory - the project directory obviously didn't exist when you started it - so you have to work your way backwards and figure out which random other product folder you started from in order to be able to actually resume that.

In theory, it's a skill issue; I should write these things down or dump enough context in order to be able to pick back up without being in the same conversation. But it just seems to kind of defeat the purpose of projects partially and feels like a pretty low hanging fruit patch to make.

There is a workaround:

ag -l "your_search_string_here" ~/.claude/projects

will at least point you to the right project.

Filed #60851 with same root cause (macOS, but mechanism is platform-agnostic — see also #48394 on Windows and #57920 on macOS worktree removal). Letting mine auto-close as dup; migrating the proposed fix here since this thread has the most traction.

Proposed fix (minimal)

Decouple session lookup from cwd path. One small-footprint option:

1. On session start, append the session ID to <git-root-or-cwd>/.claude/sessions (a plain newline-separated text file of UUIDs).
2. On /resume and --continue, read that pointer file first; fall back to today's cwd-slug lookup if absent.
3. For --resume <id>, do a global scan of ~/.claude/projects/**/<id>.jsonl so the UUID is a true global key.

Properties:

• Pointer file is KB-sized, just UUIDs — safe to commit, sync, or .gitignore.
• No secrets leave ~/.claude/.
• Backward compatible: existing slug-based layout preserved as fallback.
• Survives mv, git mv, worktree clones, symlinks.
• Non-git dirs fall back to current behavior.

Alternative

Key the session directory by git remote get-url origin hash instead of cwd path, falling back to cwd slug for non-git dirs. Rename-proof for the common (git) case.

Why --resume <id> deserves special treatment

--resume <session-id> reads like a global lookup by a content-addressable key (the UUID), but it's actually scoped by cwd. Users reasonably expect a UUID-keyed flag to work from anywhere — the global-scan fallback in step 3 above is the smallest change that delivers that expectation.

Resumability keyed to the starting cwd is a trap. In MartinLoop we learned the hard way that session identity != workspace path; workspace is one dimension of context, not the primary key. If resume only works from the original directory, users lose portability and auditability the moment they move a checkout, use a different worktree, or reopen from a sibling clone.

A stronger model is stable session id -> canonical session receipt/manifest, with cwd/worktree captured as metadata and remapping warnings on resume when needed. That keeps the safety checks without making resume itself path-fragile.

Is there any progress on this?