Session memory should not be scoped to working directory path

[kmathewmk]

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.

[yurukusa]

The directory-derived path encoding has a related edge case worth flagging for whoever picks this up: it embeds /home/$user (or /Users/$user on 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/foo on a Linux machine creates .claude/projects/-home-alice-projects-foo/memory/. Sync that whole ~/projects/foo directory (including any committed .claude/ portion) to a second Linux machine with user bob, 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:

# After moving / renaming / cloning to a different user, re-link the new path-key
# directory at the user's `.claude/projects/` to the actually populated one.
cd ~/.claude/projects
ln -s -home-alice-projects-foo -home-bob-projects-foo

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:

1. Migration path: if a auto_memory_key: field lands in CLAUDE.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.
2. Collision resolution: if two repos on the same machine both declare auto_memory_key: foo, what wins? Last-write, error, or namespaced merge?
3. Multi-worktree behaviour: with git worktrees, each worktree currently gets its own memory directory (different absolute paths). Should they share by default if auto_memory_key is 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.

[psilva2026]

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.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[psilva2026]

Why opening a new issue?

This is still relevant and a huge issue for anyone working in more then one repo.

[github-actions]

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.