Session memory should not be scoped to working directory path
Status Closed — not planned
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 5 comments · opened Apr 29, 2026 · closed Jun 4, 2026
Currently, Claude Code's auto-memory system stores memories under a path derived from the working directory (e.g. .claude/projects/-home-user-scm-myproject/memory/). This means:
- Moving or renaming a project directory silently orphans all accumulated memory.
- Switching to a different workspace for the same work starts a blank session with no prior context.
- There is no way to resume a session's memory from a different directory without manually copying files.
Expected behaviour: Memory should be associated with a named session or project identifier that the user controls, not the filesystem path. This would allow memory to survive project moves, renames, and workspace switches.
Suggested fix: Allow users to assign a named project ID (e.g. in CLAUDE.md or a config flag) that is used as the memory key instead of the directory path. The directory-derived key could remain as the default for backwards compatibility.
5 Comments
The directory-derived path encoding has a related edge case worth flagging for whoever picks this up: it embeds
/home/$user(or/Users/$useron macOS), so memory is also non-portable across machines for the same logical project — even if the relative path under~is identical.Concrete example. A project at
~/projects/fooon a Linux machine creates.claude/projects/-home-alice-projects-foo/memory/. Sync that whole~/projects/foodirectory (including any committed.claude/portion) to a second Linux machine with userbob, and Claude Code starts looking for.claude/projects/-home-bob-projects-foo/memory/— none of the prior memory loads. Same on a Mac (-Users-alice-...vs-Users-bob-...). The memory bytes are right there on disk, but the lookup key won't find them.Workaround that buys time until a stable key lands:
This is fragile (every rename / new machine needs a fresh symlink, and on Windows
.claude/projects/lives elsewhere), so it's a stopgap, not a fix. But it does at least keep the memory readable while the underlying decision about a stable project ID is being made.A few questions that probably matter for the design:
auto_memory_key:field lands inCLAUDE.md, is the existing path-derived directory auto-renamed on first run, or does the user copy it manually? Silent auto-rename is convenient but loud about file ownership — vocal copy is safer but adds friction.auto_memory_key: foo, what wins? Last-write, error, or namespaced merge?auto_memory_keyis set, or stay isolated?The OP's "directory-derived as default for backcompat" is the right shape — just worth nailing down those three before the rename ships, since they're the edges where path-keyed and id-keyed projects collide.
Some memory entries are indeed project scoped, but other aren't, therefore on top of what was already said we also loose memory lessons that are project agnostic when working in other repos.
To also bear in mind that when working with Git Worktrees, whci its usesd extensively when working with Agents to work on several tickets at the same time we also loose memory, because each worktree its on its own path.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
Why opening a new issue?
This is still relevant and a huge issue for anyone working in more then one repo.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.