/cd changes the working directory but does not relocate the session to the new project storage
Summary
/cd <path> changes the session's working directory — new transcript records carry the new cwd — but it does not move the transcript into the target directory's project storage, and no relocated record is written. The session therefore stays filed under the old project: --resume from the new directory does not list it, while the old directory still does.
No symlinks are involved here, so this is distinct from #86575 (which covers the symlink/physical-path case, and whose text confirms the intended behaviour: relocate the session "to the new directory's project storage, so --resume and --continue find it from there").
Repro
- A session recorded under project A — transcript at
~/.claude/projects/-home-user-Code-project-a/<id>.jsonl.
- Resume it:
claude --resume <id>. - Inside the session run
/cd ~/Code/project-b(a plain, existing, non-symlinked path). - The command reports no error, and the session does work in the new directory.
- Exit the session.
Expected
The transcript is relocated to ~/.claude/projects/-home-user-Code-project-b/, so /resume from project B lists it and project A no longer does.
Actual
The transcript file is still in project A's directory. Concretely, after /cd and exit:
grep -c '"type":"relocated"' <transcript>→ 0- the newest records do carry the new directory:
"cwd":"/home/user/Code/project-b"
- the file is still at
~/.claude/projects/-home-user-Code-project-a/<id>.jsonl
For contrast, another session on this machine that was relocated at some earlier point does carry the record, and it looks like this:
{"type":"relocated","relocatedCwd":"/home/user/Code/project-b","sessionId":"…"}
That session's per-message cwd fields still say the old directory, and it is nonetheless filed correctly — i.e. the relocated record is what carries the relocation, and /cd is not emitting it.
Impact
From the user's side the command silently half-works: it is named "Move this session to a new working directory", it reports success, the session behaves as if it moved — and then the session is simply missing from the picker where it was expected, and still present where it was not. Nothing surfaces the discrepancy, so the natural conclusion is that the session was lost rather than that it stayed behind.
I only noticed because I was auditing session files directly; I finished the move by hand with mv into the target project directory, after which everything behaved correctly.
Possibly the same family as #80289 (/cd does not load project-scoped skills from the new directory) — both look like "/cd updates the working directory but not the session's project association".
Environment: Claude Code 2.1.235, Linux (Kubuntu 24.04), CLI.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗