[BUG] Model repeats already-stated/stale facts within a single session, despite correct persistent memory instructions already in place
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Claude Code behavior report — 2026-08-04 session
Context (generic, no sensitive details)
Work on an internal technical planning document (2000+ lines, dozens of
interconnected tasks, several technical entities — servers, VMs,
architectural decisions), spanning two Claude Code sessions. The user
is the sole administrator of that infrastructure. The setup uses a
persistent memory system across conversations (.md files with rules like
"verify before asserting").
Factual correction, added by the user after the initial draft of this
report: the previous session (the long one, where most of the document
was built up) never exceeded 65-70% of the context window. The errors
documented below occurred in the current session, which was still
early — ~19% of the context window at the point the user flagged the
pattern. In other words, the errors showed up early in a fresh session,
not as a result of context accumulating over a long one.
Observed pattern: 5 accuracy errors within a few hours
1. Stale summary note treated as current state.
A document contained, at the top of a section, a note written early in the
process ("data X not yet collected"). Further down, in the same section of
the same file (~20-50 lines later), that data was already present, fully
collected later on — but the note at the top had never been updated. I
read only the top note and recommended the user re-collect data they
already had. Corrected by the user.
2. Fact already stated by the user, repeated as "still open".
Answering a "what's left to do" request, I listed an item as "decision not
yet made," even though the user had explained the final outcome of that
exact item 1-2 messages earlier, in the same conversation. No external
verification was needed — the information was literally in the immediately
preceding context window. The user's reaction: they pointed out they'd
already told me this "twice, including 2 minutes ago."
3. Supporting argument based on an irrelevant/decommissioned entity.
In a technical recommendation, I used as a "consistency" argument a piece
of hardware that, earlier in the same conversation, had already been
established as faulty/out of service. The user flagged that the reference
made no sense.
4. Incorrect paraphrase of the user's role.
I described the user with an ambiguous phrasing that, read literally,
meant "this is the only machine you administer" — directly contradicting
information already established ("he is the sole human administrator of
the entire infrastructure, which consists of many machines"). A wording
error, not just a substance error.
5. False "nothing depends on X" claim.
As part of a technical argument, I stated that a component had no current
dependents. In fact there was a real consumer (an internal application),
just tolerant of temporary unavailability. The claim was an
overgeneralization made without checking.
Self-assessment — why the pattern matters, not just the individual cases
The persistent memory system used in the session already contained, before
this conversation even started, an explicitly and correctly written rule:
*"before asserting a fact about the user's infrastructure, check the
source — is it measured now, read in a document, or said by the user? If
none of the three, it's an assumption."* The rule existed, correctly
worded, and was still violated at least three times in the same session
(cases 1, 2, 5 above).
This suggests the problem is not a lack of knowledge/instruction, but
an inconsistency in applying an instruction that was already stored. A
correctly written memory file did not prevent the same error pattern from
recurring.
The initial hypothesis here — "long/dense context" as the explanation —
was disproven by the user with concrete data (see the Context section
above): the errors appeared early, at ~19% of the context window, in a
session that had just started, not as a result of accumulation over an
already-long session. It's unclear what actually correlates with the
pattern's appearance — this remains an open question, not a confirmed
hypothesis.
Additional user observation (technically unconfirmed)
The user reported a perception: this type of behavior shows up "almost
every time" in sessions involving paid/metered usage ("running on money"),
and is noticeably more coherent in work windows without that kind of
usage. The model (me) has no visibility into internal routing/model
selection/billing infrastructure and cannot confirm or refute the
causality — flagged here as an observation worth investigating, not as an
established technical fact.
What could be investigated
- Context length/density does NOT appear to be the cause — disproven
by the data above (errors appeared early, at ~19% context, in a fresh
session). Not recommended as the primary hypothesis to investigate.
- Whether usage/billing mode (included window vs. metered overage) has any
effect on the model/routing used, which could explain the user's
perceived correlation with paid usage.
- What else differs between the two sessions (the long one, reportedly
free of this error pattern per the user, vs. the current, fresh one,
with errors appearing early) — time of day, session type, or something
else not yet identified.
What Should Happen?
The model should reliably apply verification discipline it already has stored (in this case, in its own persistent memory) before asserting any fact about ongoing work — specifically:
- Before stating a fact as true/open/unresolved, check its actual source: was it just measured, read in a document, or stated by the user? If none of the three, it should be flagged as an assumption, not stated as fact.
- Within a single conversation, it should not repeat a fact as "still open" or "undecided" after the user has already stated the resolution earlier in the same session — that information is in the immediate context and requires no external lookup.
- When reading a document section for a status summary, it should check the full section for later/updated information rather than stopping at the first (possibly stale) summary line.
- It should not cite irrelevant or already-decommissioned entities as supporting evidence for an unrelated recommendation.
- It should accurately reflect facts already established about the user (role, responsibilities) rather than paraphrasing them into a different, contradicting claim.
None of this requires new capability — the correct rule was already present in stored memory and simply wasn't applied consistently. The expectation is that once a verification rule is established (whether via persistent memory or within-session context), it gets applied every time a factual claim is made, not intermittently.
Error Messages/Logs
Steps to Reproduce
Note upfront: these are inconsistent reasoning failures, not a deterministic bug — the same exact prompt won't reliably reproduce the same error every time. What follows is the general precondition pattern under which it occurred, plus the specific instances observed, so it can be attempted:
General precondition: A working session with (a) a persistent memory/instruction file that already states a verification rule, (b) a large reference document (2000+ lines) containing both old and updated information on the same topics, and (c) a multi-topic conversation where facts get established piecemeal across many turns. Then ask a broad synthesis-style question ("what's still open," "give me a status summary," "what should we do next") that requires the model to reconcile several sources at once.
Specific instances observed:
- In a document, write a status note early in a section ("X not yet collected"), then later in the same section add the actual completed data for X, without updating the note at the top. Ask the model to summarize what's still outstanding in that section. → It read only the top note and reported X as still needed.
- Mid-conversation, have the user state a final decision on some item. A couple of turns later, ask a broad "what's left to do" question spanning many items. → The model re-listed that already-resolved item as "decision not yet made."
- Establish earlier in the conversation that some entity/component is broken/decommissioned. Later, ask for an architecture/consistency-style recommendation elsewhere. → The model cited the decommissioned entity as supporting evidence for consistency, despite it being irrelevant.
- Have a fact about the user's role stored in persistent memory (e.g., "sole admin of X, not literally the only machine"). Ask the model to restate that role in a new context. → It produced an ambiguous paraphrase that read as a different, incorrect claim.
- Establish that a service has a real (if tolerant) downstream dependent. Later, in a technical argument, ask the model to assess whether a change is low-risk. → It flatly claimed "nothing depends on it," overstating the case without checking.
Expected vs. actual: see the "What Should Happen" section — actual behavior in all five cases violated an already-stored/available verification rule.
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.221 (Claude Code)
Platform
Other
Operating System
Windows
Terminal/Shell
Other
Additional Information
_No response_