[BUG] Memory orphaned when working directory is renamed

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?

Memory is silently orphaned when the working directory is renamed

Summary

Per-project memory in Claude Code is stored under ~/.claude/projects/<encoded-working-dir>/memory/, where <encoded-working-dir> is the absolute path with / and . rewritten as -. When the user renames their working directory, Claude Code transparently spins up a fresh empty memory directory at the new path. The old one stays on disk forever but is never loaded again. There is no warning, no migration prompt, and no in-product surface that tells the user this happened — Claude doesn't know what it's missing, and the user doesn't know context was dropped.

Impact

Memory is the place users invest in establishing how Claude should work with them — the user's role, project conventions, validated feedback rules, references to external systems, the user's profile. Losing it silently is a big regression in collaboration quality that the user only notices indirectly (Claude stops anticipating things it used to, asks questions it had answers to, repeats mistakes it had previously been corrected on).

What Should Happen?

Proposals (ranked by complexity)

1. Explicit CLI command — minimal viable fix

claude memory migrate <old-working-directory>
# or
claude memory migrate --from ~/.claude/projects/-Users-me-Documents-MyProject

Reads memories from the old encoded path, copies into the current one, prompts for conflict resolution per file. No detection logic, just a tool the user can run when they realise.

2. Startup detection + prompt

When Claude Code initialises a project for the first time (i.e. it just created an empty memory directory), scan ~/.claude/projects/ for sibling entries whose encoded path is close to the current one (Levenshtein distance, common-prefix match, or just sharing the same parent in the original /-separated form). If any candidate has a non-empty memory/, prompt the user:

Looks like you may have renamed MyProject to MyProject.archived. There's an existing memory directory at the old path containing 27 entries. Would you like to migrate them? [yes / no / show me which entries first]

If they decline, write a .no-migrate-from-<old-path> marker in the new directory so we don't pester them every session.

3. Decouple memory from path entirely

Longer term: identify projects by a content-addressable token (e.g. a .claude-project-id file written into the working tree, like .git/config does) rather than the absolute path. Renaming or moving the directory then keeps memory associated automatically. This also helps when a project is checked out in different locations on different machines and the user wants memory to follow them (via dotfiles repo etc.) — a related but separate user request.

Adjacent considerations

• The same issue affects projects moved between directories, not just renamed. Detection logic in option 2 should account for both.
• Some encoding edge cases that make sibling-detection harder: working directories with hyphens already in their name collide with the path-separator rewrite. A ~/Documents/foo-bar and ~/Documents/foo/bar both encode to -Users-me-Documents-foo-bar. Worth checking the existing encoding scheme handles disambiguation.
• A "memory follows me across machines" feature would be a natural complement (option 3 enables it cleanly).

Workaround until then

# After renaming, manually copy across:
cp -r ~/.claude/projects/-OLD-encoded-path/memory/* \
      ~/.claude/projects/-NEW-encoded-path/memory/
# then merge MEMORY.md by hand

— but the user has to know the issue exists to do this, which is the core problem.

Error Messages/Logs

Steps to Reproduce

Reproducible example

1. Use Claude Code in a directory ~/Documents/MyProject for a while; build up a set of memories (MEMORY.md + per-topic .md files under ~/.claude/projects/-Users-me-Documents-MyProject/memory/).
2. Rename the directory: mv ~/Documents/MyProject ~/Documents/MyProject.archived (or any rename — adding .nosync to keep iCloud out, moving into a subdirectory, etc.).
3. Open Claude Code in the renamed directory. A fresh empty memory dir is created at ~/.claude/projects/-Users-me-Documents-MyProject-archived/memory/. The old memory directory remains intact on disk but is invisible to the session.

In my case I went ~3 days before noticing — Claude was missing 27 memory entries the whole time (project overview, infra config, GitLab workspace conventions, user profile, the agreed branching workflow, validated feedback rules, etc.) and was happily writing new memories into the empty new directory.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.148

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_