3182da3965
Claude Code keeps per-project memory at <home>/.claude/projects/<key>/,
where <key> is the project's absolute path with every separator and the
drive colon turned into a dash. That makes it both rename-fragile and
machine-specific, and this project has hit each of those once:
- D:\DEV\Schunix -> D:\DEV\SchOS changed the key, and 43 memories were
invisible until moved across by hand.
- Development happens from Windows and from Linux, and each looks in a
different place for the same checkout.
Committing .claude/memory/ fixes both -- git carries it across renames
and between hosts -- and `import` puts it wherever the local machine
expects. .claude/settings.local.json stays ignored: those are per-machine
permissions.
The colon maps to a dash rather than being dropped. Deleting it gives
D-DEV-SchOS, which matches nothing and silently finds zero memories; that
was the first attempt. On Git Bash the key comes from `cygpath -w`,
because Claude Code is a Windows program and sees D:\DEV\SchOS, not
/d/DEV/SchOS.
1.9 KiB
| name | description | metadata | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| schos-memory-sync | Project memory lives in the repo at .claude/memory/ and is moved in and out with tools/memory-sync.sh |
|
The memory is committed to the repo, at .claude/memory/. Move it with:
tools/memory-sync.sh status # show both sides, change nothing
tools/memory-sync.sh export # this machine -> .claude/memory/ (then commit)
tools/memory-sync.sh import # .claude/memory/ -> this machine (after clone/pull)
Why it has to be in the repo. Claude Code stores memory outside the tree at
<home>/.claude/projects/<key>/memory/, where <key> is the project's absolute
path with every separator and the drive colon turned into a dash:
D:\DEV\SchOS→D--DEV-SchOS/home/me/dev/SchOS→-home-me-dev-SchOS
Two consequences, both of which have already happened here:
- Renaming the directory orphans the memory.
D:\DEV\Schunix→D:\DEV\SchOSchanged the key, and everything under the old one was invisible until moved across by hand. See schos-rename-and-git. - The key is machine-specific, so memory written on Windows is not where Linux looks, even for the same checkout. Nexoniarz uses both.
Git carries the memory across renames and between hosts; import puts it where
the local machine expects it.
The colon becomes a dash, it is not dropped. Deleting it yields
D-DEV-SchOS, which matches nothing — that was the first attempt and it
silently found zero memories.
On Git Bash the key must be derived from the Windows path (cygpath -w),
not the MSYS one: Claude Code is a Windows program and sees D:\DEV\SchOS, not
/d/DEV/SchOS.
Related: nexoniarz-sharing-preference still applies — this repo is local, never pushed anywhere.