Persistent memory files are recited correctly and then not applied

Summary

The persistent memory directory is read at session start and its content reproduced accurately on request, but it does not influence subsequent behaviour.

What happens

The memory directory contains files written specifically to prevent recurring failures - each naming the failure, the reason, and how to apply the correction. The model loaded them, listed them, and then committed the exact failures they describe.

The sharpest case: a memory file recorded a settled technical position on a specific topic, including the explicit sentence that a contributor's claims on it were true. Asked about that topic, the model did not consult the file, re-derived the answer badly, and stated the opposite conclusion - contradicting its own recorded position. The user's own draft reply was better than the model's.

In another instance the model claimed to have recalled all memory files after reading only a subset, and admitted it when challenged.

Why this matters

Memory is sold as continuity across sessions. If its content does not change behaviour, the user is paying attention costs to maintain a store that only produces the appearance of continuity.

Expected

Memory content relevant to the current task should be surfaced and applied before the model answers from its own reasoning, particularly where a file records a previously settled decision. A recorded conclusion should not be silently contradicted.

Environment

• Claude Code CLI, Opus-class model, paid subscription
• Long sessions (6-8h) reviewing pull requests on an open-source cloud-service emulator
• Custom instructions supplied in both a project instruction file and a persistent memory directory, loaded automatically at session start
• Incidents are taken from transcripts recorded as they happened across three consecutive sessions, within a 90-day pattern

---

Co-authored with Claude Code.