[BUG] MEMORY.md entries silently dropped when file exceeds 200-line limit -- no warning on write

Resolved 💬 3 comments Opened Mar 27, 2026 by casriraj Closed Mar 27, 2026

Problem

The memory system has a 200-line hard limit on MEMORY.md. Two issues interact to cause silent data loss:

1. No warning when writing entries that push MEMORY.md past 200 lines

When Claude writes new memory entries (via checkpoint, manual save, or auto-memory), the entries are successfully written to MEMORY.md. But if the file now exceeds 200 lines, the new entries will be invisible in all future sessions -- they exist in the file but are never loaded.

There is no validation or warning during the write. The user only discovers the truncation when they see:

WARNING: MEMORY.md is 221 lines (limit: 200). Only the first 200 lines were loaded.

...in a future session, by which time the lost entries may have already caused repeated mistakes.

2. Truncation drops the most recent (most relevant) entries

Since MEMORY.md is loaded top-to-bottom and truncated at line 200, the newest entries (appended at the bottom) are the ones lost. These are typically the most relevant -- lessons learned in the most recent sessions.

Real Impact

Over 3 months of daily use, my MEMORY.md grew from 50 to 221 lines. The last 21 lines covered:

  • SQL Preset Manager patterns (added in recent session)
  • Stock Register module details (added in most recent session)
  • Key column name gotchas learned from recent bugs

These were silently invisible in the next session. The model repeated mistakes that the memory entries were specifically written to prevent. The user only discovered the data loss after noticing the truncation warning and manually checking which entries were missing.

The Silent Write Problem

The core issue is the write path has no validation. The system happily appends entries to a file it will then refuse to fully read. This creates a false sense of security -- the user sees "memory saved" but the memory is effectively discarded.

Suggested Solutions (any combination would help)

  1. Validate on write -- before appending to MEMORY.md, check if it would exceed 200 lines. If so, warn the user and suggest moving content to topic files.
  2. Show line count after write -- after any memory write, display "MEMORY.md: 195/200 lines" so users can proactively manage before hitting the limit.
  3. Auto-index -- when MEMORY.md exceeds the limit, automatically move older/longer entries into topic files and replace with one-line pointers (the pattern the docs already recommend, but done automatically).
  4. Reverse truncation direction -- if truncation must happen, prioritize recent entries over old ones (truncate from top, not bottom).
  5. Make the limit configurable -- allow users to set a higher limit in settings if their project requires more index entries.

Environment

  • Claude Code VS Code extension, Opus model
  • MEMORY.md with 221 lines (21 lines silently truncated)
  • Auto-memory system enabled
  • Truncation discovered after model repeated bugs that were "memorized"

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗