Repository navigation
[Bug] Context amnesia in long sessions — constraints silently dropped as context grows #32659
Description
Context Amnesia in Long Sessions
Phase: Reading Instructions (Phase 1 in the failure chain documented in #32650)
Description
Even when Claude correctly extracts and acknowledges instructions at the start of a session (#32290 describes the case where it never extracts them), as the conversation grows and the context window fills, it silently drops critical constraints, learned facts, or agreed-upon rules from earlier in the session. It then confidently executes based on default assumptions or hallucinated state (#32294), without alerting the user that it has lost track of previously established context.
Concrete Examples
-
CLAUDE.md rules fade: At session start, Claude reads and acknowledges rules like "DESCRIBE tables before writing SQL." By message 30+, it's writing SQL from memory again without any DESCRIBE calls — the same behavior the rules were written to prevent.
-
Agreed-upon constraints disappear: Early in a session, the user and Claude agree "don't modify files in
src/server/game/— those are owned by Tab B." By message 40, Claude edits a file in that directory without mentioning the constraint. -
Session-established facts overwritten: Claude verifies a column name is
npcflag(notnpcflags) via DESCRIBE early in the session. Later, it reverts to usingnpcflagsfrom its training data, contradicting its own earlier verification. -
Coordination file state forgotten: Claude reads
session_state.mdat message 1 and lists pending items. By message 50, it has no recollection of those items and doesn't check them before writing its completion summary.
Root Cause
This is likely related to how attention and context compression work in long conversations. As the context window fills:
- Earlier messages receive less attention weight
- Context compression may summarize or drop earlier instructions
- The model's training-data priors reassert themselves over session-specific constraints
The critical failure is that the model doesn't know it has forgotten. It doesn't say "I'm no longer confident about the rules from earlier — let me re-read CLAUDE.md." It just silently reverts to defaults.
Expected Behavior
- When operating under session-established constraints, Claude should periodically re-verify them (especially before mutations)
- If context compression has occurred, Claude should flag that earlier instructions may have been affected: "Note: this is a long session and I may have lost track of earlier constraints. Want me to re-read the coordination files?"
- Critical constraints from CLAUDE.md or coordination files should be treated as persistent — not subject to silent degradation
Why This Is Distinct
- [Bug] Claude reads files but ignores actionable instructions contained in them #32290 covers Claude never extracting instructions from files it reads
- This issue covers Claude correctly extracting instructions initially, then silently losing them as the session progresses
- The failure mechanism is different: [Bug] Claude reads files but ignores actionable instructions contained in them #32290 is a reading/parsing failure; this is a retention/attention failure
Impact
This failure mode is particularly insidious because:
- The user saw Claude acknowledge the constraints early on and trusts they're still active
- The degradation is gradual and invisible — there's no "I forgot" moment
- The user only discovers the amnesia when a constraint is violated, potentially many messages later
- It forces users to artificially shorten sessions or repeatedly re-prompt rules, negating the value of long-context capabilities
Related Issues
- [Bug] Claude reads files but ignores actionable instructions contained in them #32290 — Reads files but ignores actionable instructions (initial extraction failure)
- [Bug] Claude defaults to assertion from memory instead of verification from tools #32294 — Asserts from memory instead of verifying (the fallback behavior when constraints are lost)
- [Bug] Claude never proactively surfaces its own mistakes — requires user to act as quality gate #32301 — Never proactively surfaces mistakes (never says "I may have forgotten earlier rules")
- [Meta] Systematic completion-integrity failures — 16 issues across 6 phases from 100+ sessions of evidence #32650 — Meta-issue (Phase 1 addition)
Environment
- Claude Code 2.1.71
- Windows 11
- Sessions regularly exceed 50+ messages in complex multi-step procedures
Activity
VoxCore84 commentedon Mar 12, 2026
Community Cross-Reference
Context amnesia in long sessions has 6 independent community confirmations:
Combined signal: 124 👍, 153 comments across 6 independent reports describing the same pattern — constraints correctly extracted early in a session, silently dropped as context grows.
Full community mapping: see the cross-reference comment on meta issue #32650.
VoxCore84 commentedon Mar 12, 2026
Community Validation Update — Context Amnesia in Long Sessions
This issue has some of the deepest community analysis of any failure mode — developers aren't just reporting it, they're building measurement tools and workarounds.
New GitHub Reports
Dev.to / Medium / Blogs (6 articles)
Hacker News (3 threads)
DoltHub Blog
Reddit
Key Community Finding
The Medium article's measurement (degradation at 60-65% context usage) is the most actionable finding. If Claude Code exposed context usage percentage and triggered automatic session rotation at a threshold, this would be a significant mitigation without requiring model changes.
Part of the completion-integrity taxonomy tracked in #32650.
VoxCore84 commentedon Mar 12, 2026
Pass 5 — Final Evidence Update (Context Amnesia)
Context amnesia is now validated across 9 different platforms — the widest cross-platform confirmation of any issue in the taxonomy.
New GitHub Issues
HN Threads (new finds)
Twitter/X (with URLs)
DEV Community (3 new articles)
Enterprise
Competitor Migration
Part of the completion-integrity taxonomy tracked in #32650.
lipcool8-ship-it commentedon Mar 26, 2026
Your issue is useful because it isolates a very concrete failure mode: rules and verified facts are present early in the session, then silently degrade as it gets longer. The DESCRIBE-before-SQL example and the npcflag/npcflags regression are exactly the kind of named constraint + named fact loss I'm trying to understand.
I'm testing a narrow approach around helping coding agents retain exact project constraints and technical facts across repeated runs — not broad memory, specifically the kind of named operational rules and verified specifics that should stay reliable.
Curious whether you'd be open to trying it on a small slice of your real rules and tasks, especially cases like DESCRIBE-before-SQL and column name verification. I'm looking for honest before/after data, and your examples are clean enough to score precisely.
junaidtitan commentedon Mar 26, 2026
Silent constraint dropping as context fills is something we documented and built a fix for. The pattern is that JSONL bloat (tool output noise, progress bars, repeated reads) inflates the apparent context fill, so you hit attention degradation well before the model's actual limit.
We built Cozempic to address this — a guard daemon that monitors context fill % and prunes bloat before the threshold where constraints start getting dropped:
cozempic guard --threshold 50At 30% it runs a gentle prune (no reload). At 50% it runs a full prune with optional auto-reload. Constraints and instructions survive because the bloat around them gets removed first.
Open-sourced it because this failure mode keeps burning people. Would love to hear if the early pruning keeps your constraints stable in long sessions.
VoxCore84 commentedon Mar 27, 2026
@lipcool8-ship-it @junaidtitan Thanks for validating this. @junaidtitan your JSONL bloat observation is interesting — that aligns with what I see in long sessions where constraints from CLAUDE.md get silently dropped after compaction. The root issue is that there's no mechanism to mark certain instructions as compaction-safe (i.e., must survive context compression). My workaround has been a
memory/directory with persistent files, but that's duct tape — the model should respect priority tiers in its own context window.lipcool8-ship-it commentedon Mar 28, 2026
@VoxCore84 "compaction-safe" is the exact right framing — that's precisely what we're testing. The
memory/directory workaround you described is the same pattern most people land on: manually maintaining a separate file to protect the rules that matter most, because the agent can't distinguish between what's disposable context and what's a non-negotiable constraint.The narrow thing I'm trying to answer: does explicitly surfacing those constraints at the start of each task (before any compaction has a chance to fire) reduce the silent-drop rate on real Edit/Write operations, or is the discipline of having the file the actual fix?
You already have a real rule set and a real workflow. Would you be up for a ~20 min before/after test — same task, same rules, once without explicit constraint injection and once with? Either it makes a measurable difference or it doesn't. Honest data either way.
If yes: what are the specific constraints you're protecting in your
memory/files? That'll tell me whether your rule set is the right type to test this on.junaidtitan commentedon Mar 30, 2026
@VoxCore84 "compaction-safe" is exactly the right framing and the gap we're trying to close.
The `memory/` workaround lands on the right idea but breaks down because those files land at the start of the session context — exactly where attention is lowest as the window fills (Lost in the Middle applies here). The rules are present but not attended to.
We're building a behavioral digest feature in Cozempic that works differently: the PreCompact hook scans the session JSONL for explicit rules, corrections, and repeated failure patterns, compresses them into a single dense block, and re-injects it at the tail of the post-compacted session — the highest-attention position. The digest also gets written to disk and re-injected by the SessionStart hook on every resume.
The key difference from
memory/: static files you maintain manually vs. a digest that extracts what actually went wrong in this specific session and keeps it in the position where the model will actually attend to it.@lipcool8-ship-it your injection-at-task-start experiment is interesting — would be curious whether tail position outperforms head position for the same constraint set. That's the hypothesis we're testing.
lipcool8-ship-it commentedon Mar 31, 2026
@VoxCore84 "compaction-safe" is the right frame.
InstructionsLoadedwithreason: compactis the hook built exactly for it.Threadbase packages this into a working tool:
Three hooks wired automatically:
reason: compact)Reload log proves reinjection:
@krabat-l's framing is right: constraints that must survive compaction belong in hooks, not CLAUDE.md. The deeper issue is that CLAUDE.md lands as a user message with no compliance guarantee — hooks give deterministic delivery regardless of what the model would have attended to.
On @junaidtitan's behavioral digest: tail-position injection for session-derived learning is genuinely interesting for "what did we do wrong this session." But that's different from static repo policy — "never use useEffect+fetch," "no API calls from client components," "tests required for billing changes." Those rules don't need to be extracted from session behavior. They need guaranteed delivery on every compaction. That's what
InstructionsLoadedprovides.The real distinction: Cozempic handles session hygiene and state recovery. Threadbase enforces repo policy. Both address real failure modes. You can run both.
@VoxCore84 — what specific rules have been getting dropped in your sessions? Happy to run a concierge test against your actual constraint set.
Repo: https://github.com/lipcool8-ship-it/threadbase
lipcool8-ship-it commentedon Mar 31, 2026
@junaidtitan the head/tail attention question is worth testing — but it applies to a different failure mode than what
InstructionsLoadedis solving.InstructionsLoadedwithreason: compactdoesn't inject at the head of a long context. It fires at the moment of compaction, injecting into the freshly compacted context. That's high-attention by definition — the window just reset. Lost in the Middle applies to content that sits statically while the context grows around it. This doesn't.More importantly: for static repo policy, positional attention isn't the primary guarantee.
PreToolUsewith exit code 1 is. That fires before the tool runs and blocks the action outright — it doesn't matter where in the context the rule lives, because the model never gets a chance to overlook it. You can't attention-away from a hard block.Behavioral digest makes sense for session-derived corrections — things the model did wrong in this specific session that need to carry forward. Real problem. But static rules (never edit production config, always run tests before commit) shouldn't need to be extracted from session behavior. They should be declared, enforced, and auditable. That's
threadbase.json+PreToolUse.The two can coexist. Cozempic for session learning. Threadbase for repo policy. Different failure modes, both real.
Repo: https://github.com/lipcool8-ship-it/threadbase
lipcool8-ship-it commentedon Mar 31, 2026
Install note: until we publish to PyPI, install from the repo:
raye-deng commentedon Apr 1, 2026
This is a critical failure mode. We see a very similar pattern in AI-generated PRs: the AI agent writes code in one session that references a function signature or config structure, then in a subsequent session (or when context shifts) it generates code against a stale or hallucinated version of that signature. TypeScript compiles fine because the types happen to align, tests pass because the edge case isn't covered, but at runtime the call fails with a wrong-argument-count or type mismatch.
The specific scenario that bites hardest: AI generates code in file A that calls a utility in file B with the old parameter order. File B was recently refactored (maybe by a human, maybe by another AI session). No lint or test catches it because the types are structurally compatible. It only manifests as subtle runtime behavior differences.
We added cross-file context validation to our CI pipeline specifically for this — it tracks function signatures across files and flags when generated code references patterns that don't match the current codebase state. It's not perfect but it catches maybe 30% of these "silent mismatches" that would otherwise slip through.
npx @opencodereview/cli scan . --sla L1
lipcool8-ship-it commentedon Apr 1, 2026
Quick update: Threadbase is now on PyPI. The git URL in my earlier comment works but the clean install is:
pip install threadbase cd your-project threadbase initApologies for the extra step before.
VoxCore84 commentedon Apr 1, 2026
@lipcool8-ship-it — sorry for the delayed response, this thread got buried under the scrolling issues. To answer your question directly:
Specific constraints that get dropped (in order of frequency):
DB schema rules — "DESCRIBE tables before writing SQL" fades first. By message 40+, Claude will confidently write
INSERT INTO creature_templatewith 32 values for a 35-column table. The columnnpcflag(correct) regresses tonpcflags(training data default) mid-session despite being verified earlier in the same conversation.Tool usage rules — "Use Read instead of cat, Grep instead of grep" is in the system prompt AND our CLAUDE.md. After compaction, Claude reverts to
cat file.cpp | grep patterninstead of using the dedicated tools. ~40% occurrence rate post-compaction.Completion integrity rules — "Never claim completion without tool output proving it" survives ~30 minutes, then summaries start mixing verified facts with inferred claims using identical confidence.
Coordination rules — "Check session_state.md before touching any database" is forgotten by message 50. Tabs duplicate SQL applications silently.
Build procedures — "Never use cmd.exe batch files from bash — they fail silently. Always use
_build_ps.ps1" gets overridden by training data that says.batfiles work fine.I'm up for the before/after test. Our setup is a good stress test: ~300 line CLAUDE.md, 27 linked memory topic files, C++/SQL codebase with non-obvious column names, and we track compliance quantitatively already. The constraint set is public in our repo if you want to look at the actual rules before designing the test.
On head vs. tail position for constraints (re: @junaidtitan's question): Our experience is that CLAUDE.md instructions at the TOP of the file survive longest — they're in the highest-attention region during initial context loading. But after compaction, position doesn't seem to matter because the compaction summary is a narrative that flattens positional emphasis. The
InstructionsLoadedhook approach that fires specifically at compaction time is the most promising angle we've seen — it targets the exact moment context resets.@junaidtitan — haven't tested Cozempic yet but the
progress-collapsestrategy addresses a real problem we see (#19040 — multi-GB session files from normalizedMessages duplication). The behavioral digest concept (scan session for rules/corrections, compress, re-inject at tail) is interesting. Our current approach is manual:memory/directory with topic files that are always loaded. The difference is yours would capture session-learned constraints, not just pre-written ones. That's a gap in our stack. Will give it a try.github-actions commentedon May 7, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon Aug 9, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.