Give Claude a Memory with CLAUDE.md and Auto Memory

The most common complaint I hear about Claude is that it forgets. You explain your stack, your style and your decisions, close the session, and the next day you start from zero. Claude does remember, as long as you tell it where to write things down. Once you understand the few memory layers it has, re-explaining yourself becomes rare.

The layers, and what each one is for

Claude has separate memory systems in the app and in Claude Code. They do not share storage, so it helps to know which one you are feeding.

• Claude app memory: facts about you and your work that Claude picks up from chats.
• CLAUDE.md files: instructions you write for Claude Code. Loaded at the start of every session.
• Auto memory: notes Claude Code writes for itself as it works, per project.
• Rules and imports: ways to split instructions so only the relevant parts load.

Set up memory in the Claude app

If you also use Claude in the browser or desktop app, start here because it takes two minutes. Go to Settings, then Memory. Turn on Generate memory from chats so Claude keeps track of your role, projects and preferences, and Search and reference chats so you can ask things like "what did we decide about the pricing page last week?" Chat search needs a paid plan.

Open the list of what Claude remembers and fix anything wrong. You can also tell it directly in a chat: "Remember that I write all product copy in American English." Each Project keeps its own separate memory, which is useful when you work for different clients and do not want details leaking between them. The help center article covers the details.

Write a personal CLAUDE.md

In Claude Code, the file at ~/.claude/CLAUDE.md loads in every project on your machine. This is where your working style goes. Keep it short and concrete. A good test for every line: would Claude make a mistake without it?

# How I work
- American English in all copy and code comments.
- Ask before adding a new dependency.
- Prefer small commits with clear messages.
- When a task is ambiguous, ask one clarifying question before starting.
- Never commit secrets or .env files.

Vague lines like "write clean code" do nothing. "Run the test suite before saying a task is done" does something, because Claude can check it.

Give each project its own CLAUDE.md

Inside a project, run /init. Claude reads the codebase and writes a starting CLAUDE.md with build commands, test instructions and conventions it found. Then edit it down. Add what Claude cannot learn from the code: why you picked a library, a trap in the deployment, a naming rule the team agreed on.

Some useful details:

• A project CLAUDE.md can live at ./CLAUDE.md or ./.claude/CLAUDE.md. Commit it so your team gets it too.
• Personal notes for one project go in CLAUDE.local.md. Add it to .gitignore.
• Pull in other files with an import, for example @docs/architecture.md. Imported files still load at startup, so this helps organization, not size.
• Aim for under 200 lines per file. Longer files cost context and Claude follows them less reliably.

Scope rules to the files they apply to

When a project grows, put topic rules in .claude/rules/, one file per topic. Add a paths field and the rule loads only when Claude works with matching files:

---
paths: ["app/components/**/*.tsx"]
---
# Component rules
Use the spacing tokens from the design system, never raw pixel values.
Every interactive element needs a visible focus state.

Rules you want everywhere go in ~/.claude/rules/ instead.

Let auto memory learn from you

Auto memory is on by default in Claude Code. As you work, Claude saves notes about your preferences, corrections you gave it, and project context it cannot derive from the code. They live in ~/.claude/projects/<project>/memory/, with a MEMORY.md index whose first 200 lines load into every session. The rest of the notes are read only when needed.

You can steer it in plain language:

Remember that the staging database is reset every Monday, so never rely on data older than that.

That goes to auto memory. If you want something in CLAUDE.md instead, say "add this to CLAUDE.md". Run /memory any time to open your CLAUDE.md files, toggle auto memory, and browse what Claude saved. Everything is plain Markdown, so delete anything stale. I review mine every few weeks, the same way I clean up a design file.

Know the limits

Memory is context. Claude reads it and tries to follow it, but nothing forces it. For things that must happen every time, like formatting after each edit or blocking a dangerous command, use a hook. Hooks run as real commands at fixed moments, whatever Claude decides.

Also check what actually loaded. Run /context and look under Memory files. If your CLAUDE.md is not listed, Claude cannot see it. And if two files say opposite things, Claude may pick either one, so keep them consistent.

A simple weekly routine

1. When Claude makes the same mistake twice, add one line to CLAUDE.md.
2. When you type the same explanation twice, ask Claude to remember it.
3. Once a week, open /memory, remove stale notes, and move long procedures out of CLAUDE.md into a skill.

Start today with the personal file. Write five lines about how you work in ~/.claude/CLAUDE.md, run /init in your main project, and see how the next session feels. The official memory docs have the full load order when you want to go deeper.