Auto-memory system is ineffective: memories not reliably read or acted on across sessions
Summary
The auto-memory system (file-based memory at ~/.claude/projects/.../memory/) does not reliably influence model behavior across sessions. Memories are written but not acted on, making the system effectively useless for enforcing behavioral constraints.
Observed failure pattern
- User corrects a behavior (e.g. "always read source data before writing a DB schema")
- Model writes a memory file capturing the constraint
- In subsequent sessions, the same mistake recurs — identical correction needed again
- Model acknowledges the memory exists but did not apply it
This has been observed repeatedly in this project. Specific examples:
- Memory written: "read source data before writing any DB migration" — violated in the same and subsequent sessions, requiring the user to raise the same schema gaps 4-6 times per data type
- Memory written: "show full test output" — intermittently ignored
- Memory written: "own your code, never use passive voice to deflect authorship" — periodically reverts
Root causes (as observed)
- Context compression — the
MEMORY.mdindex is loaded but individual memory files are not pre-loaded; after context compression, previously-read memory files are gone and the model does not re-read them - No enforcement — memories are advisory; the model can acknowledge a memory exists and still not apply it
- The index is what gets loaded, not the content —
MEMORY.mdis a one-line summary per memory; the actual constraint is in the file body, which may not be read - No verification step — nothing checks whether a relevant memory was consulted before a tool call that the memory governs
What actually works in this project
The user has a hook system at ~/.claude/hooks/ (PreToolUse, PostToolUse, Stop hooks) that blocks tool calls and enforces constraints mechanically. Hooks work. Memories do not.
Expected behavior
If a memory says "do X before writing migrations," the model should not be able to write a migration without having done X. The memory system needs either:
- Mandatory pre-tool-use enforcement (not advisory loading)
- Automatic re-injection of relevant memories before tool calls that the memory governs
- Or honest documentation that memories are best-effort hints, not behavioral constraints — so users know to use hooks instead
Impact
Users write memories expecting behavioral change, get none, and lose trust in the system. The recourse is to rebuild the enforcement using hooks, which requires technical knowledge most users don't have.
3 Comments
Four to six identical corrections per data type is a useful measurement, and it is the part that usually goes unquantified.
The correction is not lost because the model is forgetful. It is lost because correcting and recording are two different acts, so nothing outlives the session where the correction happened.
What worked for us was collapsing them into one act: the moment a correction lands it gets written out as its own entry, with an author and a date, and later sessions read it back before they start. The count went to one.
four to six identical corrections per data type matches what i measured from the other side, and the number is worth putting down: across 43 real compactions in one repository, the summary kept 77% of the decisions and 0.2% of the commands that had actually run. the reasoning survives because it is prose. the invocation with the flags that worked, the error text, the span an edit replaced — those are what a summary treats as noise, and they are what you need to not repeat the correction.
so the memory file is not failing because the model is forgetful. it is failing because it stores the conclusion and the conclusion is the cheap half. "read source data before writing a db migration" is a sentence the model can agree with and still not act on, because nothing connects it to the moment it is about to write a migration.
what changed this for me was moving the read to that moment rather than to session start. before an edit or a command runs, look up what this repository already did with that file or that command, and put it in front of the model then. a constraint recalled at the point of action is a different object from the same constraint recalled at startup, even when the text is identical.
it does not enforce anything, and i want to be plain about that: the model can still ignore what it is shown. what it removes is the excuse that the information was not there. in my own use the recurrence dropped, but i have no clean measurement of by how much, so treat that as an anecdote rather than a number.
disclosure: i maintain deja, which does the above by indexing the transcripts claude code already writes to
~/.claude/projectsrather than by asking the model to record anything. the 77%/0.2% figure comes from its compaction measurements and the harness is in the repository if you want to run it on your own history.this is helpful, thank you for your contribution
On Tue, Aug 25, 2026, 12:06 PM Vlad Shulcz @.***> wrote: