Claude Code memory: how to make Claude remember your business

Open Claude Code without any setup and you will explain the same things every morning. Who your clients are. Where the proposals live. How you like things written. It forgets all of it the moment the session ends.

That is the default. Claude Code starts every session with a blank slate. The fix is not a smarter model. It is memory: a few Markdown files that get loaded before you type a word.

This guide covers how Claude Code memory works, which files load when, what auto memory adds, and how to keep it lean enough that Claude actually follows it.

How does Claude Code memory work?

Claude Code memory is a set of Markdown files that Claude Code loads into the context at the start of every session. There is no hidden database. If a fact is not in one of those files, Claude does not know it next time.

There are two kinds of memory:

1. CLAUDE.md files. You write them. They hold what is always true: what the project is, how you work, what Claude must never do.
2. Auto memory. Claude writes it. While working, it saves notes about things it learned, like a build command that works or a preference you corrected.

Both load at startup. Both are plain text you can open, edit and delete. That last part matters. You can always see exactly what Claude "remembers", and fix it when it is wrong.

Which CLAUDE.md files does Claude Code load?

Claude Code loads CLAUDE.md files from several levels, from broad to specific, and combines them. A personal file applies everywhere, a project file applies to one project, and a file in a subfolder applies when Claude works in that folder.

Files in the folders above where you start Claude Code load in full at launch. Files in subfolders load when Claude starts reading files in that folder. So a clients/CLAUDE.md with client rules stays out of the way until Claude touches a client file.

When two levels conflict, the more specific one usually wins. Better still: do not let them conflict. One fact, one place.

What is auto memory in Claude Code?

Auto memory is the notebook Claude Code keeps for itself: when it learns something useful while working, it writes a note to a memory folder for that project and reads it back next session. You do not have to ask.

The notes live under ~/.claude/projects/<project>/memory/. The index file is MEMORY.md. Claude can add topic files next to it, and reads those only when they are relevant. According to Anthropic's Claude Code documentation, the first 200 lines of MEMORY.md load at the start of each session. Anything below that is not seen up front, which is why a good index stays short and points to detail files.

What ends up in auto memory is typically:

• Commands that worked, and ones that did not
• Corrections you gave ("don't use that API, use this one")
• Preferences it picked up, for example "drafts only, never send emails"
• Facts about the project that were not in CLAUDE.md

Run /memory inside Claude Code to see which memory files are loaded, open them, and switch auto memory on or off. Read your auto memory every week or two. Most notes will be right. Some will be stale. Deleting a wrong note takes ten seconds and saves Claude from repeating a mistake for months.

What should go in CLAUDE.md, and what should not?

CLAUDE.md should hold what is true on every task, and nothing that only matters for one task. If Claude needs a fact in most sessions, it belongs here. If it needs it once a week, it belongs somewhere Claude can find it on demand.

The procedures go into skills, because skills only load when the task matches. The split is explained in how to write a skill Claude picks up. If you want a ready starting point for the file itself, my five copy-ready templates include a full CLAUDE.md you can copy.

A note on the last row of the first column. "Never" lines in CLAUDE.md are advice. Claude follows them most of the time. When "most of the time" falls short, use a hook. That is exactly what hooks are for.

How long should a CLAUDE.md file be?

A CLAUDE.md file should be short: Anthropic's documentation advises keeping each one under about 200 lines, because longer files take more context and Claude follows them less reliably. Everything in memory is loaded on every task, so every line has a cost.

Long context does not mean perfect attention. Researchers at Stanford showed this in the 2023 paper "Lost in the Middle": language models were noticeably worse at using information placed in the middle of a long input than at the start or end. A 600-line CLAUDE.md is exactly that situation. The rule on line 340 is the one that gets missed.

Three habits keep the file lean:

• Write rules, not essays. "Use American English" works. A paragraph about tone does not.
• Delete when you add. Every new line should make you ask which old line is no longer true.
• Move detail out. A pricing sheet or a style guide goes in its own file, imported or linked.

How do imports and rules keep memory organized?

Imports and rules let you split memory into smaller files without losing them. An import pulls another file into CLAUDE.md with an @ path. A rule file in .claude/rules/ holds instructions for one topic, and can be limited to certain files.

An import looks like this:

# Business context
See @docs/company.md for what we sell and to whom.
Writing style: @docs/voice.md

# Personal preferences
@~/.claude/my-preferences.md

Imported files can import other files too. Anthropic's documentation sets a limit of five hops deep, which is more than you should ever need. If you are at three, your structure is too clever.

Rule files in .claude/rules/ are useful when CLAUDE.md starts to sprawl. One file per topic: writing.md, invoices.md, client-communication.md. A rule file can carry a paths field in its frontmatter so it only loads when Claude works on matching files. Your invoice rules then stay out of a session about blog posts.

How do you set up Claude Code memory for a business?

You set up memory for a business by starting small, writing only what Claude needed and did not have, and growing it from real sessions. Here is the order I recommend:

1. Run /init in your project folder. Claude Code drafts a first CLAUDE.md from what it finds. Treat it as a draft, and cut what is generic.
2. Add the business in five lines. What you sell, to whom, and what a good outcome looks like.
3. Write your personal file at ~/.claude/CLAUDE.md: how you write, which tools you use, what you always want reviewed first.
4. Work for a week. Every time you explain something twice, add one line to the right file, or tell Claude to remember it.
5. Review auto memory. Open /memory, read what Claude saved, delete what is wrong or outdated.
6. Split when it grows. Past roughly 150 lines, move topics into imports or .claude/rules/.

This is close to how I run my own business with Claude Code. It works as an AI employee that remembers my clients, products and processes, and I still review what goes out. You can read what that looks like day to day.

Which Claude Code memory mistakes are most common?

Most memory problems come from files that are too long, out of date, or in the wrong place, not from Claude Code itself. These are the most common:

• The everything file. One giant CLAUDE.md with procedures, history and rules. Claude follows less of it, not more.
• Stale facts. An old price, a former client, a folder that moved. Claude trusts memory, so wrong memory produces confident wrong work.
• Secrets in memory. API keys in CLAUDE.md end up in every session and often in git. Keep them in environment variables.
• Personal notes in the shared file. Your preferences land on your whole team. Use ~/.claude/CLAUDE.md or CLAUDE.local.md.
• Expecting the chat to be memory. A long session feels like Claude knows you. Start a new one and that is gone. If it mattered, write it down. Use claude --continue or claude --resume when you want a specific conversation back.

Is it worth setting up Claude Code memory?

Yes. Memory is the cheapest upgrade in Claude Code: a few hours of writing, and you stop re-explaining your business every morning. It is also what turns Claude Code from a clever tool into something that works the way you do.

Start with one short CLAUDE.md. Use it for a week. Fix what Claude got wrong by changing the file, not by repeating yourself in chat. The model will get replaced many times. A clear memory of how your business works keeps paying off with every new one.