Claude Code Wrote Notes to Memory I Never Asked It To. Here Is What I Keep.

Quick Answer

Claude Code memory in 2026 is three separate things that get lumped together: auto memory (notes Claude writes for itself, on by default), the CLAUDE.md file you write by hand, and the memory tool for agents built on the API. Auto memory is the convenient one, and it is also the one that quietly bit me. It saved a throwaway workaround as if it were a standing preference and kept applying it for days. What I keep now is a short hand-written CLAUDE.md, the /memory command to audit what got stored, and almost nothing from auto memory. Below is the exact split, plus a three-question test for whether a fact earns a spot in memory at all.

Last week I asked Claude Code why it kept reaching for a date helper I had deprecated. It told me, cheerfully, that it remembered I preferred it.

I never said that.

Three weeks earlier I pasted a one-off snippet to unblock a build. Auto memory filed it away as a standing preference and had been quietly applying it ever since. Nothing broke loudly. It just made a slightly wrong decision, over and over, and cited itself as the reason.

That is the whole tension of this feature. Memory in Claude Code is genuinely useful, and it will also happily learn things you never taught it.

First: three things called "memory"

Most of the confusion online is people arguing about different features. As of mid-2026 there are three, and they behave nothing alike.

1. Auto memory. Claude writes notes to itself as it works: build commands, gotchas, "the user prefers X." It is on by default and accumulates across sessions without you doing anything. The memory docs describe it as knowledge that builds up on its own.
2. CLAUDE.md. A plain markdown file you write and commit. Deterministic. It says exactly what you put in it and nothing else. This is the part I trust.
3. The memory tool. A separate API-side primitive for agents you build yourself, documented as the API memory tool. It is not the same thing as the CLI auto memory, even though both say "memory." If you are wiring your own agent, this is your surface; if you are just using Claude Code in a terminal, it is not.

The docs even have a "CLAUDE.md vs auto memory" section, which tells you the two are worth keeping straight. They are.

The failure mode nobody puts in the title

Search "claude code memory" and you get layer diagrams and "master all 7 levels" tutorials. What you do not get, near the top, is the part that actually costs you time: auto memory can save a wrong fact, and a wrong remembered fact is worse than no memory at all.

It biases every later session silently. You are not debugging your code anymore, you are debugging a note you never wrote. There is a thread of people getting bitten by exactly this: auto memory remembering a skill or command and then reaching for it in future sessions when nobody asked. One person described it as "untraceable" behavior, which is the right word. The note is invisible until you go looking.

This is the same restraint problem I keep running into across the whole toolchain. It showed up with the slash commands I actually kept (I built about twenty, use four) and again with Claude Code hooks. More automatic is not more helpful. It is just more surface area for a quiet wrong decision.

What I keep

A short CLAUDE.md. Hand-written, committed, under about 30 lines. Project conventions that are actually stable: the package manager, the test command, "never touch the generated migration files," the two libraries we standardized on. Things a new teammate would need on day one. If a line would not survive a code review, it does not go in.

The /memory command. This opens the memory files in your editor as plain markdown. I run it every few days and read what auto memory has been writing. Half the value of memory is auditing it, and you cannot audit what you never look at.

Exactly one auto-memory habit: letting it remember build and environment quirks that are boring and true. "Dev server runs on 5174, not 3000." That kind of fact is cheap to store and cheap to be wrong about, because you notice immediately.

What I turned off (or prune)

Preference inference. This is the one that bit me. Auto memory inferring "the user prefers X" from a single action is where the junk comes from. I prune those lines on sight when I run /memory. One data point is not a preference.

Anything that belongs in code. If a decision is important enough to remember, it is important enough to be a lint rule, a template, or a comment in the repo. Memory is not version-controlled the way your code is, and it is not visible to your teammates. When I catch myself wanting Claude to "remember" a rule, that is usually a sign it should be a hook or a line in the config instead.

Cross-project bleed. Global memory that leaks a convention from one repo into an unrelated one. Keep memory scoped to the project. The broader the scope, the more likely a "helpful" note fires in the wrong place.

The three-question test

Before I let a fact live in memory (auto or CLAUDE.md), it has to pass all three:

1. Is it stable? Will it still be true next month? A pasted workaround is not stable. A test command is.
2. Is it verifiable? Could a teammate read it and agree, or is it an inference about "what I like"? Keep facts, prune guesses.
3. Would I rather it were code? If a lint rule, template, or comment would do the job better, write that instead. Memory is the fallback, not the default.

If a note fails any of the three, it does not earn the slot. This is the same discipline I ended up applying to project instruction files, which I wrote up as the cross-tool version of this.

The setup I actually run (July 2026)

• CLAUDE.md: short, committed, reviewed like code.
• Auto memory: on, but treated as a draft, not a source of truth.
• /memory audit: every few days, prune preference-inference lines.
• Rule of thumb: if it should be remembered forever, it should be code, not a note.

Memory in Claude Code is a good feature that rewards a little suspicion. Let it remember the boring true things. Do the thinking yourself.