Store per-project memory and settings inside the project directory
Problem
Per-project memory lives in ~/.claude/projects/<path-mangled>/memory/. It is already
scoped to a project — the directory name is the project path — but it is stored in the
user profile.
Anyone working on the same project from more than one machine (shared repo, Dropbox,
work/home laptops) loses it: the project syncs, its memory does not.
The current workaround is to manually copy the memory files into a folder inside the
project and maintain a hand-written "state" file summarizing what the assistant should
know. It is fragile and easy to forget.
Session state already travels. /resume carries a terminal session into the Claude Code
desktop app with the full conversation and context intact. Memory is the other half of
that state, and it does not move at all.
Proposal
An option to keep per-project memory and settings in <project>/.claude/, the same way.claude/settings.json and CLAUDE.md already live there. Syncing then happens
automatically via git or any file-sync tool, with no extra configuration.
Related
Same underlying problem, user-level config:
- #81392 — separating portable config from machine-local state under
~/.claude, so it
can be versioned as dotfiles
CLAUDE_CONFIG_DIR would be the existing escape hatch, but it is not reliable:
- #81278 —
CLAUDE_CONFIG_DIRnot honored (data separation) - #88528 — does not redirect user memory;
~/.claude/CLAUDE.mdis still loaded - #88603 — session rename writes to
~/.claude, ignoring$CLAUDE_CONFIG_DIR - #88374 —
install.shstill creates~/.claude/downloads
Even with those fixed, CLAUDE_CONFIG_DIR moves the whole profile for every project at
once, which is a different thing from letting a project carry its own memory.
3 Comments
Still relevant as of 2.1.276: the per-project store is still keyed by the mangled absolute path under
~/.claude/projects/, so the same synced project opened on Windows, macOS and Linux still ends up in three separate stores.Re-posted from 4 Sep with generic example paths.
A concrete instance, plus one technical point that I think strengthens the case: syncing the existing store cannot work as a workaround, because the store is keyed by absolute path.
The per-project directories under
~/.claude/projects/are named by mangling the project's absolute path. For example, on Windows:These projects live on Dropbox and are opened from three machines. On macOS, Dropbox is not at
~/Dropboxbut under~/Library/CloudStorage/Dropbox, so the identical project directory mangles to a different key there, and to a third one on Linux. Syncing~/.claude/projects/between machines would therefore produce three sibling stores for the same project that never meet: the project is the same, the key is not.That is why this is more than a location problem. A project's memory is currently identified by where the project happens to be mounted, which is a per-machine fact. Putting it in
<project>/.claude/fixes the identity as well as the location, because the key becomes "next to the project" instead of "the absolute path on this host".For comparison, the instruction half of this already travels, by hand:
~/.claude/CLAUDE.mdcan be symlinked into the synced folder and works on all three machines. The memory half has no equivalent, because you cannot symlink a directory whose name differs per host without maintaining one symlink per machine.Still the case on 2.1.295: the same synced project gets a separate auto-memory
store on each machine, because the store lives under
~/.claude/projects/<mangled absolute path>/memory/and the absolute path differsper OS (e.g.
D--Dropbox-project-aon Windows,-home-user-Dropbox-project-aon Linux).
Linking the open requests on the same problem so they can be triaged together:
#25739 (portable project memory across machines), #81391 (stable project
identity and cross-machine sync) and #87517 (
autoMemoryDirectoryshouldsupport local repo storage).