Teaching Claude to remember: how to stop the same mistakes coming back

You correct Claude. It apologises, fixes the mistake, and you move on. The next morning you open a fresh chat — and the same mistake is back. Maybe it is the date format you have asked it to stop using, or a library you have told it twice you do not use. And then there are the quieter problems: arithmetic that is confident and wrong, the occasional leap of logic that does not hold up.

None of this means the tool is broken. It means you have not yet given Claude a memory — somewhere to keep the lesson so the next session starts already knowing it. This post is about how to do exactly that: where memory lives, how to write rules Claude will actually follow, whether any of it happens automatically (mostly not — and that is the key thing to understand), and the separate trick for fixing bad maths.

Why it forgets in the first place

Every new conversation starts from a blank slate. A correction you make on Monday lives only inside Monday’s chat. Tuesday’s Claude never saw it. That is not forgetfulness in the human sense — it is simply that a conversation does not carry over unless you store what you learned somewhere it will be read again.

So there are really two jobs. First, give Claude a place to remember. Second, write what you put there as rules it can follow, not vague wishes. Get both right and the same correction never has to be given twice.

CLAUDE.md — the project’s memory

The single most useful thing you can do is keep a file called CLAUDE.md. It is a plain-text file that Claude reads automatically at the start of every session, before it does anything else. Whatever rules, conventions and gotchas you put in it become the standing context for that project — applied every time, with no reminding.

## House style
- Use British spelling (colour,
  organise) — never US spelling.

It lives in two main places, and you will use both:

• Project memory — a CLAUDE.md at the root of your project. Commit it to Git and the whole team (and every automated run) shares the same rules. This is where project-specific conventions go.
• Personal memory — a CLAUDE.md in your ~/.claude/ folder. It applies across all your projects and is just for you — your own preferences and habits.

You do not have to start from scratch: running /init in a project asks Claude to read the codebase and draft a first CLAUDE.md for you. From there you refine it by hand.

“Does it update itself automatically?” — there are two memories

This is the question everyone asks, and the honest answer has two halves, because Claude Code actually keeps two memories.

CLAUDE.md is the one you write, and it does not update itself. When you correct Claude, it will not quietly rewrite CLAUDE.md for you — and that is deliberate. This file is your considered, version-controlled rulebook, shared with your team; you would not want it editing itself behind your back. To add a rule you either open the file, run /memory to find and edit it, or simply tell Claude “add this to CLAUDE.md: …” and let it make the change.

The second memory is automatic. Recent versions of Claude Code keep an “auto-memory” — a notebook Claude writes to itself as it works, quietly capturing things it figures out and corrections you give it, with no action from you. It is on by default. So when people ask “can’t it just remember?”, the answer is: to a degree, it already does. But auto-memory is Claude’s working notebook, not your rulebook — it lives on your machine rather than in your repo, and only a short index of it is loaded each session. For the rules you never want to re-explain — the team conventions, the hard “never do this” — you still want them in CLAUDE.md, written by you, on purpose.

The quickest way to capture something in the moment is the # shortcut: start a line with #, like # we deploy on Fridays — never touch main after 4pm, and Claude files it straight into that auto-memory. Treat it as a fast jot, then promote the keepers into CLAUDE.md when you tidy up. The /memory command, meanwhile, shows you everything currently loaded, lets you open any file to edit, and toggles auto-memory on or off.

Whichever you reach for, the habit that changes everything is the same: the moment you correct Claude, write the correction down somewhere it will be read again. That is the whole difference between explaining a thing forever and explaining it once.

Write rules as rules, not wishes

A memory file only helps if the rules are followable. The most common reason Claude “ignores” your CLAUDE.md is that the rule was too vague to act on. Three habits make rules stick:

• Be specific and testable. “Write clean code” is a wish. “Functions do one thing; no function longer than 40 lines” is a rule.
• Give the why. “Use our api/client.ts wrapper for all network calls — it adds auth headers and retries, and bypassing it causes silent 401s.” The reason lets Claude apply the rule to cases you did not list.
• Show good vs bad. One short example of the right way and the wrong way is worth a paragraph of description.

A few rules that work well, for flavour:

# Conventions
- Dates are always ISO 8601 (2026-06-29), never DD/MM/YYYY.
- Use British spelling (colour, organise) — this is a UK product.
- Money is stored in integer pence, never floats. Floats cause
  rounding bugs at checkout.
- Never add a dependency without asking — we keep the bundle small.
- Run the test suite before saying a task is done.

The maths and logic problem needs a different fix

Telling Claude to “be more careful” with arithmetic does not work, because the problem is not carelessness. A language model predicts text; it is a brilliant pattern-matcher, not a calculator. Ask it to do compound percentages in its head and it will give you a confident, fast, and slightly wrong number.

41310 * (1 - 0.06) ** 6
= 41310 * 0.6899
= 28,500 customers

The fix is not to make it try harder — it is to stop it doing the sum in its head. Tell it to compute the answer with a tool (run a snippet of code, or build the formula in a spreadsheet) and to show the working so you can check it. Modern Claude can run code to calculate, and a number it computed and printed is something you can verify; a number it “just knew” is not.

It also helps to let it think before it answers. The newer Claude models can take an extended “thinking” step — a private scratchpad where they work a problem through before replying — and Anthropic recommends it precisely for multi-step maths and tricky logic, where it measurably improves accuracy. In practice that is as simple as asking it to “think this through carefully and show each step” before it commits to an answer.

The same idea fixes shaky logic. Ask it to think step by step and show its reasoning rather than jumping to an answer, and add a verification step — “now check that result against the original numbers.” For anything that really matters, the strongest move is to make it write a test: a test passes or fails, and that is not a matter of opinion. You can even bake this into memory:

# Reasoning
- For any non-trivial calculation, compute it with code and show
  the working. Never estimate a number you can compute.
- For tricky logic, reason step by step, then verify the result
  before presenting it.

Three reasons a memory file gets ignored

1. It is too long. A bloated CLAUDE.md is skimmed, not absorbed; the practical guidance is to keep each file under roughly 200 lines. Every line should earn its place — ask “would removing this cause a mistake?” If it keeps growing, that is a sign some of it belongs in path-scoped rule files, or in a Skill instead.
2. The rules are vague. See above — “be consistent” cannot be followed; “use 2-space indentation” can.
3. It contradicts itself. Two rules that pull in opposite directions cancel out. Review the file now and then and remove the stale lines.

When the lesson is bigger than one project

CLAUDE.md is for facts and rules. Two neighbours are worth knowing. Skills are for “always do this task this way” — a repeatable method you hand over once (we cover them in depth here). And persistent memory lets Claude keep notes that span projects and sessions, so longer-running work does not start cold each time. Different tools, same instinct: write the lesson down somewhere it will be read again.

The takeaway

Claude will not remember for you — but it will never forget what you write down. The mistakes that drive you mad are almost always corrections that had nowhere to live. Give them a home in CLAUDE.md, phrase them as rules with a reason, and make it run the numbers instead of guessing them. Ten minutes turning your last five corrections into five lines is the highest-return thing you will do with the tool all week — because it is the last time you will have to give those five corrections.