Claude Code has two persistence mechanisms, not one. CLAUDE.md is the rules you write; auto memory is the field notes Claude keeps about your project as it goes. Auto memory is on by default and requires Claude Code v2.1.59 or later. This is how to find it, audit it, and decide which mechanism a given fact belongs in.
1. Confirm it’s enabled
claude --version
You need v2.1.59 or later. From inside a session:
/memory
The panel that opens shows every CLAUDE.md and rules file currently loaded, an auto-memory toggle, and a link to open the auto-memory folder. The toggle is the canonical way to disable per-project. To disable everywhere, set in user settings:
{
"autoMemoryEnabled": false
}
Or globally via env: CLAUDE_CODE_DISABLE_AUTO_MEMORY=1.
2. Tell Claude something worth remembering
Just say it:
remember that the API tests require Redis on port 6379, and that we use pnpm not npm
Claude saves it. You’ll see “Writing memory” in the interface. The note lands as a new entry in your project’s MEMORY.md, possibly as a topic file as well if the rule deserves the detail.
3. Audit what got saved
Open /memory from a session and click the link to the folder. Everything is plain markdown. Read MEMORY.md first — that’s the index. If it’s grown past ~50 lines, Claude has been hoarding; trim back to one-liners.
Under the hood, files live at ~/.claude/projects/<project>/memory/. The <project> segment is derived from your git repo, so all worktrees and subdirectories of the same repo share one directory. Outside a git repo, the project root is used.
4. Move the storage location, optionally
If you don’t want auto memory under your home directory — for example you’d rather it sit on an encrypted volume — set a custom location in your user settings file at ~/.claude/settings.json:
{
"autoMemoryDirectory": "~/Encrypted/claude-memory"
}
The path must be absolute or start with ~/. Accepted from user settings, managed policy, or the --settings CLI flag — see footgun #3 for why project settings are deliberately excluded.
What’s actually in there
CLAUDE.md and auto memory are complementary, not competitive:
| CLAUDE.md | Auto memory | |
|---|---|---|
| Who writes it | You | Claude |
| What lives there | Rules, conventions, architecture | Build commands, debugging insights, preferences Claude noticed |
| Scope | Project, user, or org | Per git repo, per machine |
| When it loads | Every session, full file at project root; on demand for nested CLAUDE.md | Every session, first 200 lines / 25KB of MEMORY.md |
MEMORY.md is an index, not a dump. Claude keeps it short on purpose — one-line pointers to topic files like debugging.md or api-conventions.md. Topic files don’t load at session start; Claude reads them on demand when working on something they’re relevant to.
A real entry from the auto-memory directory of this site (Claude wrote this on its own after one instruction — “remember to add sources for all the articles”):
---
name: Cite sources for every article and how-to
description: User requires every article to include verifiable source links.
type: feedback
---
Every article, how-to, or guide written for the user's projects must include
a sources section with verifiable links to authoritative documentation.
**Why:** The user runs content sites where credibility depends on traceable
claims. The methodology page promises "verified against the current
version" — sources are how that promise is kept.
**How to apply:**
- For any new how-to / article / guide content authored on the user's behalf,
include a sources section at the bottom.
- Verify every URL with WebFetch before citing — pages move, redirects rot.
- For Claude Code content, the canonical doc base is
`https://code.claude.com/docs/en/<topic>`.
Claude picked the format (frontmatter + Why + How-to-apply), the filename, and added a one-liner pointer to MEMORY.md. Next session, the rule shows up in context automatically.
Footguns
Auto memory is machine-local. It does not sync across your laptop and your desktop, and your teammates will never see it. The directory lives under ~/.claude/, not in the repo. This is a feature: things Claude notices about how you work shouldn’t end up in everyone’s checkout. But every machine starts cold. If you want a rule to apply across a team, write it into a committed CLAUDE.md. If you want it to apply across all your machines, do not copy ~/.claude/ wholesale — that directory holds credentials, plugin state, and other things you don’t want spreading. Sync just the memory directory itself, or set autoMemoryDirectory to a path you already sync.
Topic files don’t load at startup. Only the first 200 lines or 25KB of MEMORY.md enter context every session. Detailed notes in debugging.md are visible to Claude only when it actively reads them. If you put a critical rule in a topic file and rely on it firing every session, it won’t. Either keep critical rules in the index, or — better — promote them to a project-root CLAUDE.md, which loads in full at every session.
autoMemoryDirectory is rejected from project settings. Setting it in .claude/settings.json will silently have no effect. The setting is only honored from ~/.claude/settings.json, a managed policy file, or the --settings flag. The reason is a security boundary: a cloned repository could otherwise redirect auto-memory writes to anywhere on your filesystem, including over sensitive files.
Compaction handles root and nested CLAUDE.md differently. Project-root CLAUDE.md re-injects after /compact because Claude re-reads it from disk. Nested CLAUDE.md files in subdirectories do not — they reload only when Claude next reads a file in that subdirectory. If an instruction “disappeared” after compaction, that’s where it went.
Auto memory will save things you might not want saved. Claude decides what’s worth remembering based on what you correct and what you confirm. If you ran a quick experiment, said “yeah keep doing that,” and moved on — that’s now in your memory, possibly forever. Audit MEMORY.md once a week. Delete what doesn’t generalize.
When NOT to use this
- You need teammates to follow the same rule. Use
CLAUDE.md(committed) or.claude/rules/<topic>.md(also committed). Auto memory is per-machine; it won’t ship. - You want enforcement, not advice. Both
CLAUDE.mdand auto memory are context, not configuration. Claude can still ignore them. For hard rules, use hooks — those run in the harness, outside Claude’s discretion. - The information changes faster than weekly. Auto memory ages. “On-call this week is Anu” goes stale by next Tuesday. Use ephemeral conversation context for transient state.
- The rule is about a specific subdirectory only. Use
.claude/rules/<topic>.mdwith apaths:frontmatter — the rule loads only when Claude reads files matching the glob. That keeps both your context window and your auto memory cleaner. - You’re prototyping anything sensitive. Anything Claude writes to memory is plain markdown sitting in your home directory. If your threat model includes someone reading those files — a shared machine, a screenshot tool, a backup that includes
~/.claude— be explicit about what you tell Claude to remember.