[BUG] /resume lists no conversations when the project history dir is a symlink AND the repo has >1 git worktree

Resolved 💬 2 comments Opened Jun 8, 2026 by kus Closed Jun 12, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Summary

In Claude Code v2.1.168, /resume reports "No conversations found" — listing zero sessions — when BOTH of these are true for the current project:

  1. ~/.claude/projects/<cwd-key>/ is a symlink (not a real directory), and
  2. the current git repo has more than one worktree (git worktree list shows ≥2).

Either condition alone works fine; only the combination breaks listing. The picker shows nothing even in its broadest scope (after Ctrl+A = all projects and Ctrl+W = all worktrees). Newly-created sessions are also not listed while this state holds.

Environment

  • Claude Code: 2.1.168
  • Host: macOS (Darwin); running inside a VS Code Dev Container (Ubuntu 24.04, linux/arm64), user vscode
  • The history dir is a symlink because the devcontainer shares Claude history with the host. (Not required to repro — a symlink to a plain local dir also triggers it; see "Ruled out".)

What we verified / ruled out

  • Not the files — the same .jsonl files (incl. multi-MB ones) resume fine in a real (non-symlink) directory; identical files fail when the dir is a symlink.
  • Not permissions / read access — readdir/readFile work via both the symlink and its realpath; the dir is writable; new sessions are written there successfully.
  • Not a missing sessions-index.json — working projects also lack one.
  • Not mount latency or the realpath target — a symlink to a plain, fast, local dir reproduces it; it's the symlink itself, not where it points.
  • Not branch/cwd metadata — sessions' recorded cwd and gitBranch match the checkout.
  • Scope toggles don't help — Ctrl+A / Ctrl+B / Ctrl+W all still show zero.

Likely cause (guess)

The worktree-aware resume path seems to canonicalize the history dir (realpath) and map sessions to worktree roots; through the symlink the canonical path is outside every worktree, so with multiple worktrees the mapping discards all sessions. With a single worktree there's no cross-worktree mapping and the list renders normally.

Workaround

Make ~/.claude/projects/<cwd-key>/ a real directory (e.g. bind-mount it instead of symlinking), or keep the repo to a single worktree.

What Should Happen?

Expected

/resume lists the project's sessions regardless of whether the history dir is a symlink or how many worktrees the repo has.

Actual

With symlink + ≥2 worktrees, /resume lists zero sessions in all scope modes. Removing either condition restores the full list.

Error Messages/Logs

Steps to Reproduce

# A real folder holding valid, resumable session transcripts (cwd=/tmp/repro,
gitBranch=main)
mkdir -p /tmp/history-store
cp /some/valid/*.jsonl /tmp/history-store/

# A git repo
mkdir /tmp/repro && cd /tmp/repro
git init -q && git commit --allow-empty -qm init        # branch: main

# Point Claude's project dir for this cwd at the store via a SYMLINK
ln -s /tmp/history-store ~/.claude/projects/-tmp-repro

# (1) ONE worktree:
claude            # in /tmp/repro
/resume           # ✅ lists the sessions

# (2) Add a second worktree:
git worktree add /tmp/repro-wt2 -b wt2
claude            # in /tmp/repro
/resume           # ❌ "No conversations found" (even with Ctrl+A / Ctrl+W / Ctrl+B)

# Restoring EITHER condition fixes it:
#   git worktree remove /tmp/repro-wt2      # back to 1 worktree, OR
#   replace the symlink with a real directory holding the same files

### Claude Model

None

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

_No response_

### Claude Code Version

2.1.168

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

Terminal.app (macOS)

### Additional Information

_No response_

View original on GitHub ↗

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