The idea

You tell Claude Code, “Use pnpm, not npm,” during a task. In a later session, you do not want to repeat that correction. Auto Memory is Claude Code’s file-based way to carry selected learnings between sessions. Claude maintains these notes; they can cover user preferences, feedback, project context, and references. Source

That makes Auto Memory useful, but it does not make it your project’s rulebook. A CLAUDE.md file is a human-maintained instruction file. Use it for instructions the project or team expects Claude Code to follow, such as required commands, coding conventions, architecture guidance, and workflows. Auto Memory and CLAUDE.md are separate kinds of context. Source

Plain English: Auto Memory is Claude Code’s local notebook for useful past context. CLAUDE.md is the project’s human-written instruction sheet.

Auto Memory is stored as local Markdown files for a project. The normal location is ~/.claude/projects/<project>/memory/. Worktrees and subdirectories in the same Git repository share that directory. The directory contains MEMORY.md, an index, plus separate files for detailed topics. These files do not automatically move to another computer or cloud environment. Source

At the start of a conversation, Claude Code automatically loads the beginning of MEMORY.md: at most its first 200 lines or 25 KB, whichever comes first. Detailed topic files are not automatically loaded at startup; Claude Code reads them when relevant. This is why a short, accurate index is more useful than treating memory as an unlimited archive. Source

A small example

Example: You are working alone on a service. You correct Claude Code: “This repository uses pnpm rather than npm.” That is a recurring preference or project detail that Auto Memory may record. Later, you can inspect the note with /memory. The command can browse, open, edit, or delete memory files; /context shows loaded memory-related files. Source Source

Now change the requirement: “Before opening a pull request, run these checks.” That is a team workflow. Put it in CLAUDE.md, where people can review and maintain it in the repository. Do not rely on one developer’s local Auto Memory for a team-wide rule. Claude Code also generally avoids saving facts it can derive from the codebase or that already appear in CLAUDE.md. Source

This distinction is practical:

  • Use Auto Memory for corrections, personal preferences, ongoing context, and pointers to external systems.
  • Use CLAUDE.md for durable, reviewable project instructions.
  • Use hooks or permission settings when an action must be technically restricted rather than merely requested. Source Source

Try it

Take five minutes. In a low-risk project, make one small correction that is not already obvious from the repository. For example: “Prefer short release-note summaries.” Start a new session. Run /memory and check whether a local Markdown note was created. If so, review it. Is it accurate? Is it specific enough to help, but not a rule the whole team needs?

Then decide where it belongs. Keep a useful personal or conversational detail in Auto Memory. Move a shared requirement into CLAUDE.md. Edit or delete stale notes with /memory. Auto Memory is enabled by default in local sessions, and you can also control it through /memory, the autoMemoryEnabled setting, or CLAUDE_CODE_DISABLE_AUTO_MEMORY. Source

Watch out

Auto Memory supplies context, not certainty. It is not hard enforcement. A note can be stale, incomplete, or applied poorly. For requirements that must block or control an action, use the documented technical mechanisms: hooks or permission settings. Source Source

It is also local readable text, not a secret store. Review what is saved, and do not ask it to retain credentials or private data. Finally, remember the startup limit: if MEMORY.md grows beyond the automatically loaded portion, later material may not be present at the beginning of a session. Keep the index focused, and keep binding project knowledge in a human-maintained instruction file. Source