Auto-memory MEMORY.md silently truncated at ~25KB; long-running projects lose recent rules without visible signal

Summary

Auto-memory MEMORY.md is loaded at session start with what appears to be a ~25KB / 200-line cap. When MEMORY.md exceeds this cap, content beyond the cap is silently dropped with only a buried warning in the system prompt. In long-running projects this is high-impact because:

1. MEMORY.md is roughly chronological — the truncated portion is the most recent rules and findings, exactly what should be preserved.
2. The warning is not surfaced anywhere obvious — it appears only as a buried line in the system prompt that the model can see but the user typically does not.
3. Effect compounds with Opus 4.7's task-focus — even when a rule survives truncation, 4.7's tendency to drop ambient instructions (well-documented in #52382, #56419, #53753, #52563) means the rule may still not be honoured.

Environment

• Claude Code: latest as of 2026-05-09
• Model: Opus 4.7 (1M context); migrated from Opus 4.6
• Project: ~60 sessions deep, long-running enterprise build (private repo)
• OS: Windows 11 Pro

Reproduction context

The pattern emerges over project longevity rather than as a clean unit-test reproducer:

1. Open a project in Claude Code with auto-memory enabled
2. Accumulate sessions over weeks/months — each session typically appends an entry to MEMORY.md
3. MEMORY.md grows past ~25KB
4. Claude starts ignoring rules that lived in the truncated portion
5. Behaviour is silent — no error, no obvious indicator, the project simply feels increasingly "off"

In my case, MEMORY.md reached 34.3KB. The harness did emit, in the system prompt at session start:

WARNING: MEMORY.md is 34.3KB (limit: 24.4KB) — index entries are too long. Only part of it was loaded. Keep index entries to one line under ~200 chars; move detail into topic files.

…but only as a buried line that I noticed only after asking Claude to investigate why it was repeating mistakes.

Related issues

These issues describe the symptom (instruction adherence problems) but do not specifically call out the underlying truncation mechanism:

• #52382 — Opus 4.7 violates "ABSOLUTELY NEVER" rules in MEMORY.md
• #56419 — Opus 4.7 ignores standing debugging instructions far more than 4.6
• #53753 — Opus 4.7 repeatedly violates explicit prompt instructions
• #52563 — Opus 4.7 regression: less precise memory/MD file writes
• #45569 — Opus 4.6 ignores its own memory files
• #33603 — CLAUDE.md hard rules consistently ignored

I believe the truncation issue is one of the underlying causes of the symptoms reported in the issues above. Fixing the truncation visibility would help users diagnose and resolve a meaningful share of those reports.

Workaround I applied

I restructured MEMORY.md from a 35.5KB chronological list into a 3.5KB tiered index (90% reduction):

• 4-section structure: ## ACTIVE RULES (cap 12, sub-categorised: ≤4 mission-critical + ≤8 process discipline) + ## PROJECT STATE + ## RECENT SESSIONS (rolling 7) + ## ARCHIVES
• Detail moved to per-topic files in memory/ (loaded on demand, no size limit)
• Older entries moved to one-line entries in memory/archive/*.md index files
• Rewrote my project's end-of-session protocol with a mandatory PowerShell size check that fails the close if MEMORY.md exceeds 25KB

The restructure recovered ~8,000 tokens of context budget at every session start.

Suggested improvements

1. Surface the size warning more visibly. At minimum, in /memory output. Ideally as a UI signal at session start when MEMORY.md is over cap.
2. Document the auto-memory size limit prominently in code.claude.com/docs/en/memory. It is currently not user-facing as far as I can find.
3. Consider a built-in consolidation routine — e.g. /memory consolidate that auto-archives older entries into topic files and keeps the index lean. Most users will not notice the truncation until something has gone wrong.
4. Consider truncation strategy. Currently truncation appears to be a hard cut at ~25KB. Since MEMORY.md is roughly chronological, the truncated portion is the most-recently-added (most-relevant) content. Truncating from the end (oldest) rather than the start (newest) would be more intuitive, or a structured-aware truncation that preserves named sections.

Why I'm reporting this

A 60-session project hit this and I had to spend a session diagnosing and fixing it. The fix on my side was non-trivial (memory restructure + protocol rewrite) and the underlying issue is plausibly affecting many other long-project users without their knowledge. A platform-level improvement would help them.