`/resume` picker shows "No conversations found" when project subdir is a symlink

Resolved 💬 3 comments Opened May 15, 2026 by jjscarafia Closed May 19, 2026

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):

  1. claude/resume"No conversations found to resume".
  2. claude --resume <uuid> against any session inside that subdir → works.
  3. claude --continueworks (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.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗