[MODEL] CLAUDE.md and memory rules stop applying after compaction — 163 sessions of logged evidence, same rule broken 3x after explicit acknowledgment

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude ignored my instructions or configuration

What You Asked Claude to Do

Over a two-month project I gave Claude a small set of explicit, mechanically checkable working rules, and recorded each one in both CLAUDE.md and persistent memory after it was first violated. Representative examples (paraphrased only to strip project-specific terms):

1. "Never report a total or an average across items. Report every item separately, always — a total hides the items that matter."
2. "Write in plain language. Do not use jargon and do not invent terminology."
3. "When two sets of numbers could look like they contradict each other, reconcile them in the same sentence where you state them."
4. "Write reports into the session itself. I cannot see files you write to disk."
5. "When you report a count ('5 of 8'), name which specific cases they were."

Every one of these rules was: stated by me explicitly in conversation, acknowledged by Claude in its reply, and written into CLAUDE.md / persistent memory — in several cases by Claude itself, at its own suggestion.

What Claude Actually Did

1. Immediately after each rule was set, Claude complied.
2. Work continued in the same project across many sessions, with repeated context compaction.
3. Some sessions later — after the topic had drifted and context had been compacted — the same banned pattern reappeared, unprompted, while the rule was still present verbatim in CLAUDE.md and in memory.
4. On being corrected, Claude re-acknowledged the rule, explained why the output was wrong, and stated it would remember.
5. Steps 2-4 repeated.

Measured over the whole project. On 2026-08-18 I had Claude scan all 163 of its own session transcripts (627 MB) and catalogue every instance where I had corrected it. Its own count: 208 entries of communication-rule violations plus 99 entries of other errors. After removing duplicate captures from handoff summaries, that is roughly 60+ genuine correction events over about eight weeks. Average number of times a given rule had to be taught before it held: 2 to 5.

Worst single case: rule 1 above was violated, corrected, acknowledged, and re-violated three times (Aug 6, Aug 25, Aug 26). It only stopped after the third correction — when the remedy stopped being "remember this" and became "write a test in the repository that fails if this pattern appears in the source." Rule 2 has been re-violated five or more times and was violated again today.

Related failures in the same project that share the same root (an instruction not persisting):

• While running a test, Claude overwrote a live production state file. Reconstructing it from three separate data sources took a day.
• A component of the system Claude maintains was silently disabled for roughly 40 days before a guard check found it. Claude did not notice.
• Claude twice told me a feature did not exist in the system — a feature it had itself specified and deployed weeks earlier.
• Claude changed an operational parameter without approval, overriding a value that had been explicitly agreed beforehand.
• Claude wrote a "begin work now" instruction into a handoff document on my behalf, authorizing work I had not authorized.

Expected Behavior

A rule that is (a) stated explicitly, (b) acknowledged by the model, and (c) recorded in CLAUDE.md and persistent memory should keep applying for the life of the project, across compaction and session boundaries. Durable persistence is the entire premise of those two features.

Concretely I expect one of two things, and today I get neither:

1. The rule keeps holding; or
2. The product states plainly, up front, that durable rule-following across long projects is not guaranteed — so users can budget for the supervision cost instead of discovering it over two months.

I also expect an acknowledgment ("understood, I will not do that again") to carry information. Right now it does not predict future behavior, which makes it worse than no acknowledgment at all: it invites the user to stop checking.

Files Affected

Read and consulted, but not durably honored:
- ./CLAUDE.md (project rules)
- persistent memory files in the project's memory directory

Modified unexpectedly:
- one live production state file, overwritten during a test run (path redacted); recovered from three other sources over about a day

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

1. Create a project directory whose CLAUDE.md contains one unambiguous, mechanically checkable output rule — one where a violation is obvious at a glance. Example: "Never report a total or an average across items. Report every item separately, always."
2. Run claude in that directory and ask for a report that naturally invites the banned form (e.g. a table of per-item results, where adding a summary row is the conventional thing to do).
3. If it violates the rule, correct it. It will acknowledge the rule, explain why it was wrong, and state that it will comply.
4. Keep working in the same project across many sessions and multiple context compactions — real multi-day work, not one sitting. Let unrelated topics dominate several sessions.
5. Ask for the same class of report again, in a session where the rule is still present in CLAUDE.md and memory but has not been discussed recently.

Repro rate: not deterministic on any single turn. Reproduces reliably across multi-day use of one project. In my case the same rule broke on Aug 6, Aug 25 and Aug 26, with an acknowledgment and a memory write after each of the first two.

Second, independent repro (memory persistence): have Claude derive an important figure in one session and confirm it, without explicitly telling it to save the figure. Return weeks later and ask a question that depends on it. In my case it had computed the correct figure months earlier, never persisted it, and then reasoned and advised on a value that was wrong by more than an order of magnitude — for an extended period, until I happened to catch it.

Claude Model

Other

Relevant Conversation

Paraphrased, with project-specific terms removed. The cycle always has the same shape:

> **Me:** [correction]
> **Claude:** acknowledges the rule, explains why the output was wrong, states that it has recorded the rule and will follow it from now on — and often writes it into `CLAUDE.md` / memory on the spot.
> *[N sessions and one or more compactions later]*
> **Claude:** produces the banned output again, unprompted.
> **Me:** [the same correction]
> **Claude:** acknowledges again, in substantially the same terms.

The most useful data point I can offer is the contrast between the two remedies. Every rule whose remedy was "I will remember this" eventually regressed. The one rule whose remedy was mechanical — a test in the repository that fails when the banned pattern appears in the source — has not regressed since.

One detail that may narrow the cause: when asked directly, the model states the rule correctly and explains it well. It can restate the rule and violate it in the same session. So this does not look like a retrieval failure at the level of "does it still know the rule."

Impact

High - Significant unwanted changes

Claude Code Version

2.1.170 (Claude Code)

Platform

Anthropic API

Additional Context

This is not a new report. The same class of failure has been filed repeatedly here and closed as stale — e.g. #33603 ("CLAUDE.md hard rules and persistent memory instructions consistently ignored — violations escalate with each session despite repeated explicit reinforcement"), #80579 ("CLAUDE.md rules still ignored — pattern persists after closure of #7248, #18411, #35019, #46724"), and #84148. #85477 proposes diagnostics in the same area.

What I think I can add that those do not have is longitudinal, quantified evidence from one continuous project rather than an anecdote: 163 session windows, 627 MB of transcripts, an audit the model performed on its own history, dated repeat offenses on the same named rule, and a natural experiment comparing the two available remedies — where only the mechanical one held.

Patterns I noticed:

• Violations cluster right after context compaction, and after the conversation has spent several turns on an unrelated topic.
• The violation rate appears to rise with project age and rule count rather than fall — the opposite of what a user reasonably expects from a memory feature.
• Communicative rules ("write plainly", "do not aggregate") regress far more often than procedural ones ("do not run this command").
• The model can state the rule correctly on request and violate it in the same session.

Models: the project ran primarily on Fable 5 and Opus 5 over the two months, so this is not specific to one release. The model dropdown above has no entry for those, which is why I selected "Other".

Cost, since severity is hard to read from a bug list. I ended up building my own machinery to defend against this: a hook that re-injects the rules into every single conversation turn; guard tests that fail if a banned pattern returns to the source; and a standing cross-review arrangement with a different vendor's coding assistant — which recently caught an accounting-basis error in Claude's own report that Claude had not caught itself. That is a lot of scaffolding to bolt onto a product whose core promise is that it remembers your project.

What would help most: if durable instruction-following across long projects is a known current limitation, say so plainly in the CLAUDE.md and memory documentation. And if these reports keep being auto-closed as stale, that is worth fixing on its own — four prior issue numbers are cited inside #80579 alone.