Skip to content

Make Claude's auto-memory portable across machines #201

@vredchenko

Description

@vredchenko

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:

  1. Move current memory files into smartem-devtools/claude-code/memory/.
  2. Review for anything not appropriate for a public repo (today's set looks clean — generic professional content only).
  3. Commit and push.
  4. On each workstation, set up the symlink:
    ln -s <repo>/claude-code/memory ~/.claude/projects/-home-vredchenko-dev-ERIC/memory
    
  5. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementMinor improvements to existing functionalitysmartem-devtools:claudeClaude Code configuration, skills, and prompts

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions