Claude Code Memory: What It Remembers and How

Claude Code memory is two things: CLAUDE.md files, instructions you write that load at the start of every session, and auto memory, notes Claude writes for itself from your corrections and preferences (Claude Code docs: memory). The docs name these two as what carries knowledge across sessions, because each one starts with a fresh context window. Below is where each kind lives, what loads and how to view and edit it, checked against the docs on October 3, 2026, then how I use it on this site.

What does Claude Code remember between sessions?

Only what is written to disk. The docs compare the two systems like this (CLAUDE.md vs auto memory):

Both load at the start of every conversation, and Claude treats both as context, not enforced configuration. The conversation itself is not memory: /clear starts fresh while keeping project memory, and /resume returns to an earlier conversation (commands). Subagents load your CLAUDE.md files unless they are the built-in Explore or Plan or set omitClaudeMd (what loads at startup), but only a fork gets the main conversation's auto memory; a custom subagent can keep its own with the memory field (subagent memory).

Where do CLAUDE.md files go?

In one of four scopes, listed here from broadest to most specific, which is also their load order (choose where to put CLAUDE.md files):

Claude Code loads CLAUDE.md and CLAUDE.local.md from your working directory and every directory above it and concatenates them, so no file overrides another; files in subdirectories load when Claude reads files there (how CLAUDE.md files load). An @path/to/import reference imports another file, up to four hops deep, but imported files still load at launch, so imports organize a long file without saving context (imports). The docs suggest under 200 lines per CLAUDE.md and moving rules for one part of the codebase into .claude/rules/ files with a paths field, which load only when Claude works with matching files (path-specific rules).

My personal ~/.claude/CLAUDE.md holds working rules: the language Claude talks to me in, never commit or push without my explicit approval, no AI attribution in commits. The project CLAUDE.md holds this site's positioning and copy rules and imports AGENTS.md with an @AGENTS.md line (AGENTS.md vs CLAUDE.md). What belongs in the file is covered in what to put in CLAUDE.md.

What does auto memory save?

Notes Claude decides are worth keeping, in four kinds it records as a type field in each file's frontmatter (auto memory):

• user: your role, expertise and working preferences
• feedback: corrections you give Claude and approaches you confirm
• project: ongoing work, deadlines and decisions Claude can't derive from the code or git history
• reference: where to find information outside the project

It skips anything it can derive from the codebase and anything your CLAUDE.md files already say, and it does not save something every session. Auto memory is on by default in local sessions. To turn it off, use the toggle in /memory, which saves autoMemoryEnabled to ~/.claude/settings.json, set "autoMemoryEnabled": false in one project's settings, or set CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 (enable or disable auto memory).

Where is auto memory stored, and how much loads?

In a folder per project, with an index and one topic file per memory (storage location):

~/.claude/projects/<project>/memory/
├── MEMORY.md           # Index, one line per memory, loaded into every session
├── user_role.md        # One memory
├── feedback_testing.md # One memory
└── ...                 # Any other topic files Claude creates

The <project> path comes from the git repository, so all worktrees and subdirectories of one repo share one folder, and it is not shared across machines or cloud environments. The first 200 lines or 25KB of MEMORY.md, whichever comes first, load at the start of every conversation, and topic files load only when Claude reads them with its file tools (how it works). If a write leaves the index over a limit, the write succeeds but Claude gets an error telling it to rewrite the index, because everything past the limit is dropped on the next load (memory index errors). To keep the folder elsewhere, set autoMemoryDirectory in settings to an absolute path or one that starts with ~/ (storage location).

How do you view and edit memory?

Run /memory. It lists your CLAUDE.md, CLAUDE.local.md and other memory file locations across user and project scopes, holds the auto memory toggle and opens the auto memory folder; selecting a file that doesn't exist yet creates it (view and edit with /memory). Every memory file is plain markdown you can edit or delete, and /context shows which CLAUDE.md and rules files loaded into the current session, under Memory files.

Asking Claude to "remember that the API tests require a local Redis instance" saves to auto memory; to put a rule in CLAUDE.md instead, say "add this to CLAUDE.md" or edit the file yourself. Messages like "Saved 2 memories" or "Recalled 2 memories" mean Claude is writing or reading the memory folder. To find outdated or conflicting instructions, /doctor prompt-audit reports findings and changes nothing until you ask; it needs Claude Code v2.1.283 or later (audit your instruction files).

How do I use memory on this site?

For the repo behind this site, auto memory follows the layout the docs describe: one fact per file, plus a MEMORY.md index.

~/.claude/projects/<project>/memory/
├── MEMORY.md
├── cheberko-local-port.md
├── cheberko-indexing-script.md
├── outreach-consent-geo-artifact.md
├── manuals-no-filler.md
└── ...

Saved rules include these:

• Run the dev server on port 3100, never 3000.
• Request recrawls after every deploy.
• Check consent from a non-EU location. A fact-checker agent caught an outreach finding of consent "denied" with no banner. It was true only because the check ran from Bulgaria: Wix sets denied only for EU visitors.
• Write manuals without filler. I rejected early drafts as padded, and the fix became a fixed manual format and this saved rule.

One fact per file keeps each index entry to one line, which is what the 200-line limit rewards, and lets me fix or delete one rule without touching the others. Rules that apply in every project, such as never pushing without my approval, sit in my personal CLAUDE.md instead.

What can memory not do?

Enforce anything. CLAUDE.md content arrives as a user message after the system prompt, with no guarantee of strict compliance, and the docs send any instruction that must run at a fixed point, such as before every commit or after each file edit, to a hook (troubleshoot memory issues). So the rules that must hold on this site do not live only in memory: scripts/content_lint.py fails the run on em dashes, links to removed or missing pages and banned phrasing, and I approve every commit and push, so no agent pushes on its own.

Memory also does not keep what was said only in chat. After /compact, the project-root CLAUDE.md and auto memory are re-injected from disk (what survives compaction), but an instruction given only in the conversation can disappear, and the docs' fix is to add it to CLAUDE.md (instructions lost after /compact).

Where to go next

Memory holds what Claude should know; a hook makes sure something happens every time. For rules an agent must not skip, see Claude Code hooks that enforce the rules agents forget.