Claude Code memory is how Claude remembers your instructions across sessions. Each new session begins with a fresh, empty context, so on its own Claude would forget everything the moment you close the window. Memory fixes that. The main piece is a plain text file called CLAUDE.md that Claude reads at the start of every session, plus an automatic layer where Claude writes notes to itself. You do not need to code to use it: a CLAUDE.md file is just a Markdown document with your rules and facts written in plain English.

What Claude Code memory is

Think of it as a briefing you hand Claude before it starts work. Instead of typing "we use British spelling," "the build command is npm run build," or "put new pages in the src folder" every time, you write those facts down once. Claude loads them automatically at the start of each session and treats them as context. There are two systems working together, and the difference is who writes the notes.

You write itCLAUDE.md filesInstructions and rules you author by hand: standards, workflows, project layout, "always do X" rules.
Claude writes itAuto-memoryNotes Claude saves for itself as it works, based on your corrections and the things it learns about your project.

Both are loaded at the start of every session.

The CLAUDE.md file, and where it lives

A CLAUDE.md file can sit in a few different places, and each place has a different reach. Claude loads all of them and stacks them together, from the broadest to the most specific, so a rule for one project can build on top of a rule that applies to everything you do.

CLAUDE.md locations
PProject file./CLAUDE.md — checked into the repo, shared with the whole teamShared
UUser file~/.claude/CLAUDE.md — your personal preferences across all your projectsYou
LLocal file./CLAUDE.local.md — private to you on this one project, kept out of source controlPrivate

The project file is the one most teams care about. Because it is checked in alongside the code, everyone who works on the project, and everyone's Claude, gets the same briefing. A new teammate opens the folder and Claude already knows the conventions. There is also an organization-wide managed file that IT can deploy to every machine, useful for company-wide standards and compliance reminders.

What goes in it

The rule of thumb: write down anything you would otherwise re-explain. Good candidates include the commands to build and test the project, coding standards and naming conventions, where different kinds of files live, and any "always do this, never do that" rules. The official guidance is to keep each file focused and reasonably short, because a tighter file is one Claude follows more reliably.

You do not have to write it from scratch. Running /init asks Claude to look through an existing project and draft a starting CLAUDE.md with the build commands and conventions it can find. You refine from there.

Good to know: CLAUDE.md is context, not a hard rule. Claude reads it and tries to follow it, but it is guidance, not an enforced lock. The more specific you are ("use 2-space indentation" beats "format code nicely"), the more consistently Claude sticks to it.

Pulling in other files with @

You can keep a CLAUDE.md tidy by pointing it at other files instead of pasting everything in. Writing @path/to/file.md anywhere in your CLAUDE.md tells Claude to pull that file's contents in at startup. It is handy for referencing a README, a coding guide, or a shared set of standards without copying them.

CLAUDE.md
# Project standards See @README.md for the overview. Git workflow: @docs/git-guide.md # Personal, shared across worktrees @~/.claude/my-preferences.md

An @ reference expands the linked file into context when the session starts.

Auto-memory: the notes Claude keeps for itself

The second system needs no writing from you at all. As Claude works, it decides when something is worth remembering, a build command it figured out, a fix that solved a recurring bug, a preference you corrected, and quietly saves a note. Those notes are machine-local and tied to the project, so the next session starts already knowing what the last one learned. Auto-memory is on by default. When you tell Claude "always use pnpm, not npm" or "remember the tests need a local database," this is where it lands.

A real example

Say you run a small agency and you keep a folder of client reports that Claude helps you draft. Every session you found yourself repeating the same three things: never use em-dashes, always put finished reports in the "Delivered" folder, and the client's name is spelled "Colibri," not "Colibry." So you write them into a CLAUDE.md once:

CLAUDE.md
# Writing rules - Never use em-dashes. Use commas or periods. - Client name is spelled "Colibri". # Where things go - Finished reports go in the Delivered/ folder.

From then on, every session opens with Claude already knowing all three. You stop re-typing them, and a colleague who opens the same folder gets the identical behavior for free. Later, when you correct Claude on something new mid-session, auto-memory quietly files that away too, so the correction sticks without you touching the file. That is the whole point: write it once, and the knowledge compounds instead of resetting.

The /memory command

Running /memory inside a session is your control panel for all of this. It lists every CLAUDE.md and rules file currently loaded, so you can confirm Claude is actually seeing your instructions. It lets you open any of those files to edit them, toggle auto-memory on or off, and jump to the folder where the auto-memory notes are stored so you can read or clean them up.

/memory

Open the memory panel to see what is loaded and manage it. Click to copy.

If Claude ever seems to ignore an instruction, /memory is the first place to check: if the file you expected is not on the list, Claude cannot see it, and the fix is usually moving it to a location that gets loaded.