# Claude Code Auto Memory Not Working? The 200-Line Limit That Hid My Newest Memories Claude Code auto memory not working? Only the first 200 lines or 25 KB of MEMORY.md load. Cause, one-minute check, and the fix that cut my index. Topic: Claude & MCP Published: 2026-10-30 URL: https://productivitytech.io/claude-code-auto-memory-limit/ In the [October 2026 audit of my Claude Code knowledge base](/claude-code-memory-lessons/) one failure stood out for day-to-day work: Claude Code auto memory not working the way I expected. My **13** newest memories never reached a new session. This post is that row alone — symptom, cause, a one-minute check, and the rewrite that took my auto-memory index from **202** lines to **102**. It sits next to Layer 2 in the [five-layer Claude Code memory system](/claude-code-memory-system/) and next to the [CLAUDE.md trim](/claude-md-too-long/). Examples use **Acme** and **Example Client**, never real clients. ## Symptom: Claude forgets what it learned last week The symptom looks like this: you correct Claude, it saves the memory, and a fresh session acts as if the correction never happened. In my case the topic files existed and the index listed them, but the **13** newest entries were below line **200**. ## Cause: only the first 200 lines or 25 KB load The [Claude Code memory docs](https://code.claude.com/docs/en/memory) are explicit about how auto memory loads: > The first 200 lines of `MEMORY.md`, or the first 25KB, whichever comes first, are loaded at the start of every conversation. Content beyond that threshold is not loaded at session start. That limit is on the **index** only. Topic files under the auto-memory folder are not loaded at startup; Claude reads them on demand when it needs them. If the index never points at a topic file inside the load window, that memory stays invisible at session start. My auto-memory `MEMORY.md` was **202** lines. New memories were **appended at the bottom**. The **13** newest sat past the **200**-line window, so they were never read. Nothing in my setup failed loudly. The index looked healthy if you opened the whole file; Claude only ever saw the top of it. ## Check yours in one minute Auto memory lives under the project memory directory the docs describe: `~/.claude/projects//memory/`. Inside it you get a `MEMORY.md` index and one topic file per memory. You can also open the folder from a session with `/memory`. From your shell (placeholders only — use your own project directory name): ```bash # Line count of the auto-memory index wc -l ~/.claude/projects//memory/MEMORY.md # Size of the same file du -h ~/.claude/projects//memory/MEMORY.md ``` If `wc -l` is over **200**, or `du` shows more than **25 KB**, the bottom of the index is outside the load window. Open the file and look at the last entries: those are the ones Claude may never see at session start. ## Fix: group by topic and keep the index short I did not delete the memories. I rewrote the index the way the docs describe Claude keeping it concise: one line per entry, detail in topic files, stale rows merged or dropped. What I changed: 1. **Group by topic** instead of a chronological dump with the newest at the bottom. 2. **One line per memory** in `MEMORY.md`, linking to the topic file that holds the detail. 3. **Keep the whole index well under 200 lines / 25 KB** so every link sits inside the load window. After the rewrite the index was **102** lines, and all **239** memories were still linked. Every link, including the newest, now sits inside the load window. ## Move durable facts out of auto memory Auto memory is the session learner: preferences, corrections, patterns Claude writes for itself. Per the docs it is machine-local, with one directory per git repository, and it is not shared across machines or cloud environments. It is a poor home for facts you want durable, reviewable, and shared across tools. I move long-lived facts into the knowledge-base repo — client files for Acme and Example Client, playbooks, decisions — and keep that repo’s own index short. That split is the same idea as [Karpathy’s LLM Wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f): a short schema and index, with synthesis in topic files. The always-on rules stay in one `AGENTS.md` (see the [CLAUDE.md size post](/claude-md-too-long/)); the wiki holds knowledge; auto memory stays small. The free [personal-memory template](https://github.com/Sinfjell/personal-memory-template) is the durable home I point people to: one rules file, size limits, client folders, and `/setup`. Use it for facts that should outlive a single project’s auto-memory folder. ## What newer Claude Code versions do differently When I hit this, a write past the limit did not alert me. The [current docs](https://code.claude.com/docs/en/memory) describe a clearer feedback loop after Claude writes to `MEMORY.md`: - If the file is **near** a limit, Claude Code reminds Claude to shorten it — keep one line per entry, move detail into topic files, merge or drop stale entries. - If the file is **over** a limit, the write still succeeds, but Claude Code **returns an error telling Claude to rewrite the index**, because everything past the limit is dropped on the next load. I still treat the load window as a hard constraint, not something the reminder will manage for me. Group by topic, keep the index short, and put durable facts in the knowledge base so the index never has to grow into a dump again. ## Start from the template 👉 [**github.com/Sinfjell/personal-memory-template**](https://github.com/Sinfjell/personal-memory-template) — click *Use this template*, make the copy private, run `/setup`. Product page: [/products/personal-memory-template/](/products/personal-memory-template/). The March post is still the architecture. The [seven failures post](/claude-code-memory-lessons/) is the audit table. This post is the auto-memory row. [Subscribe below](#foot-sub) if you want the later pieces in the series by email. ## FAQ: Claude Code auto memory