Build1 publisher3 min readPublished
Claude Code's auto memory relearned the same Chrome fix in three separate repositories
One developer's scan of 21 per-project memory directories found 17 empty and nine notes in the other four. The duplication follows from keying memory to the git repository, which no setting changes.
The Engineer · Build desk
What happened
- A shell loop over ~/.claude/projects/*/memory on one Mac on 2026-09-09 turned up 21 per-project auto memory directories created by Claude Code.
- Seventeen of those directories held nothing at all: no MEMORY.md index and no topic files, despite the project having been opened at least once.
- The author disabled the feature in the single repository where an autonomous agent runs, and says context size was not the reason for the decision.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Memory is keyed by git repository, so a preference about the machine rather than the project has to be relearned in every repo where it comes up, and there is no scope setting to widen.
- exposure Whatever an unattended session decides to keep sits outside the transcript retention sweep and survives until a human or Claude edits the file, which puts it in scope for anyone auditing what an agent believes.
- decision Because the directory appears on the first run and the feature ships on, leaving it enabled is now a choice someone has to make per repository rather than a default nobody touched.
- cost Anyone disabling this to reclaim context is paying attention to the wrong budget: at three index lines against a 200-line ceiling, the real cost is the unreviewed writes, not the token count.
What happens at the end of a session is narrow and worth knowing before you form an opinion about it. Claude decides whether anything is worth keeping. If it is, it writes a topic file and one index line into `~/.claude/projects/<project>/memory/`, where the project key is derived from the git repository, and every worktree and subdirectory of that repo shares the one directory [4]. The permitted notes are typed in frontmatter: `user`, `feedback`, `project`, `reference` [2]. The one that matters for agent work is `feedback`, which holds corrections you gave and approaches you confirmed [2].
The directory is created eagerly. The author confirmed this by opening a throwaway project and finding an empty `memory/` on the first `claude -p` run, before a second session could have taught it anything [15]. So 21 directories is a count of repositories opened at least once, not of repositories that produced a memory [11]. The 81 percent empty rate [1] is partly a census of scratch checkouts. If your machine has fewer of those, your ratio will not look like this one.
The duplication is the finding that survives that caveat. Three of the four non-empty directories, 75 percent of them [3], had independently saved the same correction: how to open a URL in a specific Chrome profile, because the plain `open` command picks the wrong one [14]. Project A recorded that the profile flag does not work with `open`, Project C saved a mapping table of profile directory names, Project D wrote "always open URLs in profile 1 for this repo" [14]. That is a fact about the machine, stored three times because the key is the repo [4]. Auto memory is also machine-local and is not loaded into subagents, except a fork, which inherits the parent conversation [7]. That knowledge does not travel between repos, and it does not reach the subagents doing the work either.
Context cost turns out to be a small concern here. The first 200 lines or 25KB of `MEMORY.md`, whichever comes first, load at the start of every conversation, and topic files are read on demand [6]. The largest index in this scan was three lines [16], which is 1.5 percent of the line budget [4]. Nine topic files across four directories over months of use averages 2.25 files each [2]. Nothing here is under load.
What persists is the part that earns an audit. Memory files are excluded from the transcript retention sweep, so they stay until you or Claude edits them [8]. The author, who had read the memory documentation and never opened the directories it describes [18], turned the feature off in the single repository where an autonomous agent runs, and states the reason was not context size [17]. For an unattended repo the question is custody: who writes the note, who if anyone reviews it, and what actually removes it. On the documented behaviour the answers are Claude, nobody, and an edit [8].
The setting can be flipped three ways: `/memory` writes `autoMemoryEnabled` to user settings, the same key can be set per project in `.claude/settings.json`, and `CLAUDE_CODE_DISABLE_AUTO_MEMORY=1` covers the environment [9]. Only the second lives inside the repository, which makes it the one that travels with a checkout to everyone else running the same agent.
What to watch
- Whether Anthropic adds a machine-scoped or cross-repository memory tier, which would remove the relearning described here.
- Whether auto memory becomes visible to subagents beyond forks, since that is where unattended agent work actually runs.
- A larger scan across several machines, which would show whether 17 empty directories out of 21 is typical or an artifact of one user's scratch projects.