auto-memory write-instruction ignores `autoMemoryDirectory` setting

Resolved 💬 3 comments Opened May 14, 2026 by chekos Closed May 18, 2026

The auto-memory section of the system prompt hardcodes the harness's default memory path (derived from the project-hash → ~/.claude/projects/<hash>/memory/) instead of interpolating autoMemoryDirectory from .claude/settings.local.json. Load respects the setting; write-instruction does not.

Repro

  1. Set autoMemoryDirectory in .claude/settings.local.json to a non-default path, e.g.

``json
{ "autoMemoryDirectory": "/Users/me/projects/myrepo/.memory" }
``

  1. Start a session in that project. Ask the model to remember something.

Expected: the new memory file is written under .memory/ (the configured directory), and the canonical MEMORY.md there is updated.

Actual: the model writes the new file to ~/.claude/projects/<hash>/memory/ (the hardcoded default), updating a stale MEMORY.md that nothing else reads. The MEMORY.md that was loaded into context comes from .memory/ (correct), so the model has two contradictory paths in front of it and the system-prompt one wins by default.

Net effect

autoMemoryDirectory half-works: loads from the right place, writes to the wrong one. To get correct behavior today, the project's CLAUDE.md has to explicitly override the system-prompt path — a per-project workaround, not a fix.

Likely root cause: the auto-memory template injected into the system prompt isn't rendered against the resolved autoMemoryDirectory value; it interpolates the default project-hash path unconditionally.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗