`/resume` picker shows "No conversations found" when project subdir is a symlink
Summary
When the project subdir under ~/.claude/projects/ is a symlink (not a real
directory), the interactive /resume picker reports "No conversations found
to resume" — even though session JSONL files exist behind the symlink and
can be loaded directly via claude --resume <uuid> or claude --continue.
Environment
- claude-code 2.1.142
- Linux (Debian 13, kernel 6.12). Also reproduced in a containerized Linux
workspace that bind-mounts ~/.claude/ from the host.
Repro
Setup:
cd ~/.claude/projects/
mkdir -- -home-user-real-path
# create one or more session .jsonl files inside whose recorded
# cwd matches /home/user/real/path
ln -s -- -home-user-real-path -home-other-path
Then from a shell whose cwd encodes to the symlink subdir name
(/home/other/path in the example above):
claude→/resume→ "No conversations found to resume".claude --resume <uuid>against any session inside that subdir → works.claude --continue→ works (loads the most recent session).
If the symlink is replaced by a real directory with the same contents, the
picker lists the sessions correctly.
Expected
The /resume picker should follow symlinks in ~/.claude/projects/ the same
way --resume <uuid> and --continue do.
Use case (why symlinks)
We share session history between a host machine and a containerized dev
environment that mounts ~/.claude/ from host. The host and container see
different absolute paths for the same workspace (e.g. /home/jjs/odoo/19/data/custom/X
vs /home/odoo/custom/X), which encode to different project subdir names.
A symlink from the container-encoded name to the host-encoded real dir
lets sessions created on either side land in the same physical files.
Everything works except the picker.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗