Problem
Claude Code's auto-memory system stores files at ~/.claude/projects/-home-vredchenko-dev-ERIC/memory/ — a path that:
- Is local to whichever machine the user is on
- Does not travel to a different workstation
- Is not accessible to a future developer inheriting the project
The auto-memory feature (loading MEMORY.md into context, writing memory files via the Write tool) is hardcoded to this path. "Portability" means getting the directory's content to travel with the repo and stay in sync across machines.
Val works from three different machines and wants memory to follow him and to be inheritable by future collaborators.
Three approaches considered
A) Symlink (recommended)
- Move existing memory files into
smartem-devtools/claude-code/memory/.
- On each machine:
ln -s <repo>/claude-code/memory ~/.claude/projects/-home-vredchenko-dev-ERIC/memory.
- Auto-memory keeps working transparently; writes land in the repo working tree.
Pros: zero behavioural change needed from Claude; existing mechanism transparently writes to the repo.
Cons: one-time symlink setup per machine; memory writes are uncommitted until reviewed; public-repo discretion required before each commit.
B) Instruct Claude via CLAUDE.md to read/write from a repo path
- Memories live in
smartem-devtools/claude-code/memory/.
- CLAUDE.md instructs Claude to use that path instead of the auto-memory dir.
Pros: no symlink, no per-machine setup.
Cons: fights Claude's hardcoded system-prompt instructions; brittle — Claude may forget and write to the wrong path.
C) Documentation only — copy-paste convention
- Memories live in the repo as plain docs.
- New machine = manual copy into the local memory dir.
Pros: no setup magic.
Cons: drift between machines is the default state; lowest fidelity.
Recommendation
Go with A. Concrete steps:
- Move current memory files into
smartem-devtools/claude-code/memory/.
- Review for anything not appropriate for a public repo (today's set looks clean — generic professional content only).
- Commit and push.
- On each workstation, set up the symlink:
ln -s <repo>/claude-code/memory ~/.claude/projects/-home-vredchenko-dev-ERIC/memory
- Optional belt-and-braces: a section in the repo's CLAUDE.md instructing Claude to flag memory writes that mention names, emails, or anything specific that might warrant manual review before commit.
Open questions
- Other Claude Code projects (outside ERIC) also have local memory dirs — out of scope for this ticket but worth being aware of.
- Branch strategy: small standalone branch + PR, or direct to main if the team's convention allows.
- Whether to add a hook that surfaces uncommitted memory changes during normal git workflow (so they don't go unnoticed).
Context
This emerged from a session where memory had accumulated significantly during the SmartEM Agent authentication design work, and it became clear that those memories would be lost the moment work moved to a different workstation.
Problem
Claude Code's auto-memory system stores files at
~/.claude/projects/-home-vredchenko-dev-ERIC/memory/— a path that:The auto-memory feature (loading
MEMORY.mdinto context, writing memory files via the Write tool) is hardcoded to this path. "Portability" means getting the directory's content to travel with the repo and stay in sync across machines.Val works from three different machines and wants memory to follow him and to be inheritable by future collaborators.
Three approaches considered
A) Symlink (recommended)
smartem-devtools/claude-code/memory/.ln -s <repo>/claude-code/memory ~/.claude/projects/-home-vredchenko-dev-ERIC/memory.Pros: zero behavioural change needed from Claude; existing mechanism transparently writes to the repo.
Cons: one-time symlink setup per machine; memory writes are uncommitted until reviewed; public-repo discretion required before each commit.
B) Instruct Claude via CLAUDE.md to read/write from a repo path
smartem-devtools/claude-code/memory/.Pros: no symlink, no per-machine setup.
Cons: fights Claude's hardcoded system-prompt instructions; brittle — Claude may forget and write to the wrong path.
C) Documentation only — copy-paste convention
Pros: no setup magic.
Cons: drift between machines is the default state; lowest fidelity.
Recommendation
Go with A. Concrete steps:
smartem-devtools/claude-code/memory/.Open questions
Context
This emerged from a session where memory had accumulated significantly during the SmartEM Agent authentication design work, and it became clear that those memories would be lost the moment work moved to a different workstation.