[BUG] Symlink resolution changes project key, silently orphaning conversations and memory

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?

When the working directory is a symlink, Claude Code resolves it to the physical path before computing the project key used to store conversations under ~/.claude/projects/. If the symlink target differs from the symlink path (which is the whole point of a symlink), a different project key is computed, and claude -c cannot find previous conversations.

This causes silent data loss: conversations, memory files, and tool-result artifacts become orphaned under the old project key with no error explaining what happened. Even claude -c <conversation-id> fails, because conversation IDs are scoped to the computed project key.

My setup:

• ~/projects/claude/second-brain is a symlink to an iCloud-synced Obsidian vault at ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/second-brain
• Previous sessions stored conversations under the key: -Users-dav-projects-claude-second-brain (from the symlink path)
• After a Claude Code update, the key became: -Users-dav-Library-Mobile-Documents-iCloud-md-obsidian-Documents-second-brain (from the resolved iCloud path, with spaces and tildes also sanitized to -)
• claude -c returned "No conversation found to continue" with no further explanation
• The 1.9 MB conversation file and project memory were still on disk, just under the old key

What Should Happen?

Claude Code should use process.env.PWD (the logical path maintained by the shell) rather than the realpath when computing the project key, as proposed in #44456. At minimum, claude -c <id> should search across all project keys, not just the current one.

Error Messages/Logs

$ cd ~/projects/claude/second-brain  # symlink to iCloud path
$ claude -c
No conversation found to continue
$ claude -c 9de202c6-0d70-405a-82de-49e6bca302d4
No conversation found to continue

Meanwhile, the conversation data exists:

$ ls ~/.claude/projects/-Users-dav-projects-claude-second-brain/
9de202c6-0d70-405a-82de-49e6bca302d4.jsonl  # 1.9 MB, dated Apr 12
memory/

And the new (empty) project key:

$ ls ~/.claude/projects/-Users-dav-Library-Mobile-Documents-iCloud-md-obsidian-Documents-second-brain/
# empty — created by new session, old conversations not here

Steps to Reproduce

1. Create a symlink to a project directory:

``bash
ln -s /some/deep/or/special/path ~/projects/myproject
``

1. cd ~/projects/myproject && claude
2. Have a conversation, build up memory. Exit.
3. Observe the project key in ~/.claude/projects/ uses the symlink path.
4. Update Claude Code (or wait for the path resolution behavior to change).
5. cd ~/projects/myproject && claude -c
6. "No conversation found to continue"
7. ls ~/.claude/projects/ shows a new key derived from the resolved physical path, while the old key with all conversation data still exists.

The issue is especially likely with:

• iCloud-synced directories (paths contain spaces and tildes)
• Stow-managed dotfiles
• NFS/network mounts accessed via symlinks
• Monorepos with convenience symlinks

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown — conversation was created on v2.1.x sometime before April 12, 2026

Claude Code Version

2.1.91 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Workaround: Manually move the conversation .jsonl files and memory/ directory from the old project key to the new one under ~/.claude/projects/.

Related issues:

• #44456 — Root cause: CLI discards logical symlink path, uses realpath
• #46342 — Related: -r doesn't find sessions when project entries are symlinks
• #28201 — Same root cause on Windows (junction points)