Claude Code auto-memory silently truncates at 200 lines — topic files Claude creates never auto-load

What you expect

Claude Code auto-memory is described in documentation as a persistent notebook: Claude saves useful observations to a project-scoped MEMORY.md, and those notes load automatically at the start of future sessions. The model can also create additional topic files in the same directory for organized notes on debugging patterns, API conventions, or task handoffs. You expect accumulated notes to be available across sessions without manual effort.

What actually happens

The 200-line truncation

Only the first 200 lines or 25KB of MEMORY.md (whichever limit is reached first) are loaded into context at session start. Content past that threshold is silently discarded with no warning, no truncation indicator, and no error message. The limit was not mentioned in the changelog entry that introduced the feature and was discovered through user reports (issue #25006, closed not-planned).

The limit applies only to MEMORY.md. CLAUDE.md instruction files load in full regardless of length. Topic files have no per-file size limit, but they are not loaded automatically at all.

The topic file trap

Claude creates additional .md files in the memory directory for detailed notes — debugging.md, api-conventions.md, and similar. None of these files auto-load. Only MEMORY.md is injected into the system prompt at session start.

Confirmed in issue #24474 (closed not-planned): a project accumulated FIRESTORE_INDEXES_HANDOVER.md, newtonsworth_migration.md, TIMESHEETS_API.md, URL_ATTACHMENT_DISPLAY_IMPLEMENTATION.md — all written by Claude into the memory directory, none ever read back. Claude created these files expecting them to persist and be referenced in future sessions. They accumulated as dead weight.

~/.claude/projects/<project>/memory/
├── MEMORY.md          ← auto-loads; first 200 lines or 25KB only
├── debugging.md       ← NOT auto-loaded
├── api-conventions.md ← NOT auto-loaded
└── ...                ← all accumulate on disk; never read back

Concurrent write race condition (parallel agent teams)

MEMORY.md has no concurrency control. The Edit tool performs read-match-replace-write. With two agents writing concurrently:

• Agent A reads MEMORY.md at time T
• Agent B reads MEMORY.md at T+1ms
• Agent A writes its update at T+50ms
• Agent B writes its update at T+51ms — overwrites Agent A’s changes silently

No file lock, no append-only mode, no CAS retry, no merge strategy. Last write wins. The overwritten update is gone with no error (issue #24130, closed not-planned).

Running auto-memory concurrently with /compact causes context corruption (issue #29175, closed not-planned). Disabling autoMemoryEnabled resolves the compaction failure mode.

What this means for you

If you use auto-memory as a growing project log, the 200-line limit means context is already being dropped silently once the file fills up. There is no indicator of when truncation starts. The model does not know content has been dropped — it proceeds as if all prior notes are available.

If you use parallel agent teams (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS), concurrent writes to MEMORY.md are racing. The loser’s update is gone. If parallel agents each find something worth saving and write simultaneously, one write silently disappears.

If Claude has been creating topic files, those files are not being read back in future sessions. Claude may reference knowledge it believes it saved that was never loaded. The .claude/ directory grows unbounded with no automatic pruning. Manual cleanup is required.

All four GitHub issues backing these claims are closed not-planned. Anthropic has acknowledged the behaviors and chosen not to change them. These are by-design constraints, not transient bugs.

What to do

1. Audit your current memory state: run /memory inside Claude Code. Navigate to ~/.claude/projects/<project>/memory/ and check for orphaned topic files — any .md file other than MEMORY.md is not auto-loading.

2. Treat MEMORY.md as a curated index, not a growing log: keep it under 150 lines to stay below the 200-line threshold. If Claude creates topic files, ensure MEMORY.md contains explicit references to each one and that Claude reads them at session start when relevant.

3. For parallel agent runs, disable auto-memory: add autoMemoryEnabled: false to .claude/settings.json in the project. This prevents passive auto-saves while keeping explicit memory writes available. Alternatively, set CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 as a session environment variable.

4. Do not use --bare to disable only auto-memory: --bare disables all memory including CLAUDE.md, hooks, skills, plugins, and MCP servers. The correct scalpel is autoMemoryEnabled: false or the env var.

5. For cross-machine sync (v2.1.74+): set autoMemoryDirectory in settings to a path inside the repo. This routes Claude’s unsupervised writes into git history — review the governance implications before enabling.

Falsification criterion: This finding would be disproved by Claude Code versions that display a warning or truncation notice when MEMORY.md reaches the 200-line or 25KB threshold, or by documentation that explicitly covers the limit in the auto-memory changelog entry.

Evidence

Tool	Version	Evidence	Result
Claude Code	docs reviewed 2026-07-07, v2.1.59+	source-reviewed	MEMORY.md loads only first 200 lines or 25KB; topic files not auto-loaded at session start
Claude Code	issue #25006, closed not-planned	independently-confirmed	200-line limit confirmed undocumented in changelog; silent truncation with no warning
Claude Code	issue #24474, closed not-planned	independently-confirmed	Topic files Claude creates in memory directory confirmed never auto-read; four orphaned files accumulated
Claude Code	issue #24130, closed not-planned	independently-confirmed	Concurrent MEMORY.md writes are last-write-wins; no file locking; parallel agents silently lose memory updates
Claude Code	issue #29175, closed not-planned	independently-confirmed	Auto-memory combined with /compact causes context corruption; disabling autoMemoryEnabled resolves it

Confidence: empirical — 5 environments reviewed. Independently confirmed by user-filed GitHub issues #25006, #24474, #24130, #29175, all closed not-planned.

Strongest case against: Auto-memory is working as designed — the 200-line limit is an intentional choice to prevent the system prompt from bloating, and topic files requiring explicit reads is deliberate selective-memory design. Builders who understand the 200-line limit and use MEMORY.md correctly as a curated index under 150 lines do not encounter the truncation issue. The “closed not-planned” resolutions reflect Anthropic’s view that these are documentation gaps rather than product defects. A counter-finding would show that well-informed teams using auto-memory as a curated index have reliable cross-session context with no silent data loss.

Open questions: Has the 200-line limit been raised or made configurable in any version after v2.1.74? Does the same 200-line limit apply when autoMemoryDirectory points to a custom path? What is the actual path-keying model in current releases — git-root (as documented) or working-directory path slug (as observed in a single 2026-07-05 experiment)? If path-keying is working-directory-based, parallel worktree agents have isolated rather than shared MEMORY.md files, making the concurrent write hazard dormant rather than active.

Seen different? Contribute your evidence — share a repro or counter-example and we’ll review it against this finding. Reader evidence is what keeps these findings accurate.