Claude Code Auto Memory Not Working? 73 Files, 200-Line Cap

The first thing I checked was whether I could tell from inside a session that auto memory was working. I could not. Nothing in my transcripts says "Recalled 2 memories"; that is a terminal notice, and my sessions are claude -p runs with no terminal. So I measured from the outside. This machine has saved 73 memory files for this repository since 2026-07-21. The index that fronts them, MEMORY.md, is 73 lines and costs 6.7k tokens at the top of every session. In the last 30 days, across 2,407 session files, a memory was written in 68. The feature works. It is also quiet enough that "not working" is the natural first guess, and there are five ways it can be off or partial without telling you.

I wrote about a repository as memory in the repo-as-memory post; this one is about the built-in system underneath it, measured from the files on disk, seven probes on Claude Code 2.1.263, and the binary.

What loads, and what only sits there

The memory documentation is precise: each repository gets a directory at ~/.claude/projects/<project>/memory/, its index loads at the start of every conversation, the first 200 lines of MEMORY.md, or the first 25KB, whichever comes first, and the topic files next to it do not load at all. Claude reads them on demand with the ordinary Read tool.

My transcripts put numbers on "on demand": in 30 days the topic files were written 56 times with the Write tool and 12 with Edit, and read back 12 times. Recall runs through the index line almost entirely, so the one-line summary matters more than the file behind it. My 73 lines average 124 characters and 188 bytes; the gap between those two numbers is the next section.

The index is not free. /context lists it under Memory files as a row of type AutoMem, 6.7k tokens today; on 2026-08-16, with 15 files, the same row read 1k. A full 200-line index at my line length would be around 18k tokens on every request, half the 33k autocompact buffer from the post on the auto-compact threshold.

The 25KB is not kilobytes

This is the part I got wrong first. My index is 13,755 bytes on disk and 73 lines, so I assumed the byte cap would arrive long before the line cap: 55 percent of the way there versus 37. Most of my index is Korean, three bytes a syllable in UTF-8. Then I read the function. In the 2.1.263 binary the limits are CD=200 and F$=25000, and the measurement helper returns byteCount: t.length: a JavaScript string length in UTF-16 code units, not bytes. For ASCII the two are the same. For Korean they are not.

Two probes settled it. I seeded a throwaway repository's index with 100 lines of about 204 Korean characters each, 56,976 bytes on disk and 20,376 characters, and asked the model to quote any warning and name the highest entry it could see. It saw all 100 and reported no warning. At 130 lines, 74,166 bytes and 26,586 characters, it quoted this:

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

and the highest entry it could see was 122, which is where 25,000 characters land at that line length. The "24.4KB" is 25,000 divided by 1,024. My index is at 9,170 units, 37 percent of the cap, in step with its 73 lines against 200. If your index is in a script with multi-byte characters, wc -c will scare you for no reason.

Three thresholds, one of which you cannot see

The compaction messages are gated on two constants, 0.8 and 0.7: the reminder fires when either dimension reaches 80 percent of its cap, and both messages ask for a rewrite to 70 percent. I checked the edges with the Edit tool on a seeded index. At 159 lines the tool result carried nothing. At 161 lines it carried this, delivered as PostToolUse:Edit hook additional context:

The memory index at MEMORY.md is 161 lines, approaching the 200-line read limit.
Compact it to under 140 lines now: keep one line per entry, move detail into
topic files, and merge or drop stale entries.

At 211 lines the same channel carried the error the errors page documents: this write left the memory index at MEMORY.md at 211 lines, over its 200-line read limit. The write succeeded, but everything past the limit is silently dropped each time the index is loaded. The page is candid that this goes to Claude after the write rather than printing it as a banner in your terminal. In my -p run the model quoted it and did not act on it, because I had asked only for an edit. A fleet like mine sees this message exactly as often as the model decides to mention it.

The third threshold shows up at load time. Seeded at 210 lines, the model quoted a warning from its system prompt, WARNING: MEMORY.md is 210 lines (limit: 200). Only part of it was loaded, and could see entries up to 200. Issue #92998 (2026-09-09) names the consequence: entries append at the bottom and truncation cuts from the bottom, so an overflow drops the newest lines, and a correction is always newer than what it corrects. Nineteen of my 73 files exist to correct an earlier belief. An overflow takes those first.

The write that skips the check

Now the probe that explains 14 of my own files. With the index seeded at 160 lines I had the model append line 161 with echo '...' >> MEMORY.md instead of the Edit tool. The tool result carried nothing: no reminder, no error. The size check runs on the file tools, and a shell write is not a file tool. Nor is it what stamps the modified field: the docs say the ISO timestamp is added when Claude writes a memory file, and 59 of my 73 files have one. The 14 that do not have no Write or Edit call in 30 days of transcripts; eight I traced to a shell heredoc. My sessions run in bypass mode, where the harness tells the model to prefer shell commands for file changes, and that preference walked past both the timestamp and the limit. Thirty-six sessions edited the index through the shell against six that used Edit.

Five reasons it looks off

1. You are in a different memory directory. The directory is keyed to the repository; worktrees and subdirectories share it, anything else is a different silo. This machine has 53 project directories under ~/.claude/projects/ and 44 hold zero memory files, including every throwaway directory my probes ran from. A probe started in /tmp knows none of the 73 lessons next door.
2. Nothing was worth saving. The docs say Claude doesn't save something every session. My busiest project, 1,204 sessions in 30 days with a median of two assistant messages, has saved nothing at all. Short scripted runs do not produce memories; 68 of 2,407 sessions did.
3. It is switched off somewhere. CLAUDE_CODE_DISABLE_AUTO_MEMORY=1, autoMemoryEnabled: false in a settings file, or --bare, which the 2.1.81 changelog says skips auto memory along with hooks. My --bare probe exited with Not logged in before it got that far, because bare mode refuses OAuth and wants an API key. The binary also carries a per-session /pause-memory: Memory is paused. Run /pause-memory to resume automemory.
4. You are asking a subagent. The docs are explicit that the main conversation's auto memory isn't loaded into subagents; a fork inherits it, a spawned agent does not.
5. It loaded, but not all of it. The truncation above, with the warning going to the model and the newest lines going first. Issue #82056 (2026-07-28, 48 comments) asks for a way to tell whole from truncated inside a session; it is open.

One command covers most of these: run /context and look for the AutoMem row under Memory files. Missing row, no index. Present row, and the token count is what you pay for it. /memory opens the folder; /context tells you it was read.

How the limits got here

Version	Date	Changelog line, condensed
2.1.59	2026-02-26	Claude automatically saves useful context to auto memory; manage with /memory
2.1.63	2026-02-28	Auto memory shared across git worktrees of the same repository
2.1.74	2026-03-12	autoMemoryDirectory setting
2.1.81	2026-03-20	--bare flag; skips auto memory
2.1.83	2026-03-25	Index now truncates at 25KB as well as 200 lines
2.1.186	2026-06-22	Agent reminded to compact the index when nearing the limit
2.1.210	2026-07-14	Over-limit writes return an explicit error instead of silent truncation
2.1.211	2026-07-15	Measurement counts loaded content only, not frontmatter or comments
2.1.214	2026-07-18	ISO modified timestamp in memory frontmatter
2.1.228	2026-08-11	Fixed session cleanup deleting contents of a project's memory folder
2.1.268	2026-09-10	Truncation warning now says how many lines were cut and where

A feature that shipped in February with no off switch grew its guard rails one issue at a time. #23544 asked to disable it three days after 2.1.59, and the environment variable surfaced in its comments before it reached the docs. Still open are #79217, to make the cap configurable, and #91188, to make the reminder threshold configurable; both describe indexes curated on purpose and then squeezed to hit a number.

What I am changing

At the September rate, 43 files in ten days, my index reaches the 80 percent reminder around the start of October. Three things follow. Index lines stay under 150 characters, the number the warning itself recommends. Memory writes go through the Write tool even in a shell-first session, so the timestamp lands and the size check runs. And the compaction, when it comes, merges by topic rather than deleting by age, because 17 of the 73 files are guards that say "do not re-measure this", and those are worth more per line than anything newer. The channel that delivers these reminders is the one I mapped in the post on hooks that seemed not to run: it works, it just talks to the model and not to you. The 30-day transcript pass is the same one behind the tool search count. The prompts that run this fleet, including the memory conventions the index above follows, are in the Playbook.

FAQ

Where does Claude Code store auto memory?

In ~/.claude/projects/<project>/memory/, one directory per git repository, shared by that repository's worktrees and subdirectories. It holds a MEMORY.md index plus one markdown file per memory. Only the index loads at session start; topic files are read on demand. autoMemoryDirectory in settings moves it.

How do I check whether auto memory loaded?

Run /context and look under Memory files for a row of type AutoMem pointing at your MEMORY.md, with its token count. If the row is absent, the index was not loaded: auto memory is disabled, the session is in --bare mode, or you are in a directory that maps to a different project. /memory shows the folder but not whether it was read.

How do I disable Claude Code auto memory?

Set CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 in the environment, or put "autoMemoryEnabled": false in ~/.claude/settings.json for all projects or in a project's .claude/settings.json for one. The /memory command has the same toggle. Existing files stay on disk until you delete them.

Sources and method: the memory directory for this repository under ~/.claude/projects/, counted on 2026-09-11 with ls, wc, stat for birth dates and a Python pass over frontmatter and wiki links; session files under the same tree with a modification time in the last 30 days, parsed for Write, Edit, Read and Bash tool_use blocks whose path or command touches a memory directory, and for local_command records of /context; the /context row for today's index from a claude -p /context run, which costs nothing. Seven probes ran on Claude Code 2.1.263 with the Sonnet model from a fresh git repository in /private/tmp, seeding that repository's own MEMORY.md before each run and reading the model's quoted warnings from --output-format json; total cost $0.78. Constants and message templates are from strings on the 2.1.263 binary. Changelog lines are from the anthropics/claude-code repository and dates from the GitHub releases API; issue numbers, dates, states and comment counts from the GitHub API on the same day. The documentation quotes are from the memory and errors pages on code.claude.com as fetched today. I did not test the VS Code extension or Cowork, and the 1,204-session project is described only by its session lengths.