Why Claude Code Forgets Your Corrections — and How to Fix It (2026)

The correction usually never gets written down

A correction typed into a chat is conversational context. It shapes the rest of that session and then the session ends. Claude Code starts the next one from your files — CLAUDE.md, the repo, whatever you point it at — and your correction was in none of them.

This is the majority case and it's mundane. It feels like forgetting a lesson because you experienced it as teaching. Mechanically, nothing was ever saved. It's the same gap behind Claude Code starting each session without your project context — the tool is stateless by design, and only files bridge sessions.

Written down isn't the same as acted on

Here's the part that changes the advice, and it's documented rather than anecdotal.

On March 22, 2026, an issue was filed on the anthropics/claude-code repository titled "Claude repeatedly fails to apply its own memory/feedback — same mistakes recur across sessions." The reporter's description is precise: "Claude Code's memory system correctly stores feedback and rules, but the model consistently fails to apply them. The same class of errors repeats across sessions despite the memory files being updated multiple times (5+ updates for the same issue)."

Their examples are the kind everyone recognizes:

• Memory says always `cd` to `backend/` before running backend commands and always `cd` to `frontend/` before `vite build`. Commands still run from the wrong directory, producing build failures or silent no-ops.
• Memory says always rebuild `dist` after `App.jsx` changes and always copy `public/` files to `dist/`. The steps get skipped and a stale bundle gets served.
• Memory says uncommitted changes get lost on sync. Files still get copied ad-hoc to production without a commit, and the change silently reverts on the next sync.
• A fix from a previous session — swapping marmot.svg for marmot.png — was never committed, reverted, and had to be requested again.

The reporter's summary is the sentence to keep: "The memory system captures knowledge but doesn't reliably influence behavior." They called it an "Alzheimer problem," on Claude Code CLI with Opus 4.6 and file-based memory.

Two things to be straight about. The issue was closed as not planned, so this is a user report rather than an acknowledged defect. And it demonstrates something inconvenient for the obvious conclusion: in that case, adding more storage would not have helped. The rule was stored. Five times.

Long sessions bury the rule you set at the start

There's a third mechanism that looks like defiance and isn't. In a long session, an instruction from early on can fall out of reliable reach — practitioners who write about this describe it precisely: the model isn't ignoring what you said at the top of the session, it can no longer see it well enough to retrieve it. The correction you gave an hour ago is technically in the conversation and functionally gone.

That's why the same correction can hold for twenty minutes and evaporate at minute ninety, and why it's also the mechanism behind knowledge files getting squeezed out of context as a session runs long.

A correction without its trigger is just trivia

Most corrections are conditional: when deploying, before running backend commands, if you touched App.jsx. Written into a growing instructions file, the condition survives as prose the model has to notice applies. There's no mechanism that surfaces "always cd first" at the moment a command is about to run.

So the failure isn't only about whether the rule exists. It's that the rule exists in a place with no relationship to the moment it's needed.

Adding it to `CLAUDE.md`. The right first move, and it genuinely works for stable, unconditional conventions. Its limits are the ones above: the file grows, it's loaded whole, and a line buried at position 180 competes with everything else for attention. The #37314 report is what the far end of this approach looks like.

Repeating the correction more forcefully. ALL CAPS, "IMPORTANT:", "NEVER". Mildly effective, and it doesn't scale — once six rules are shouting, none of them is emphasized.

`/clear` after two failed corrections. A real technique that experienced users recommend: if a correction hasn't taken after two tries, wipe the session rather than accumulate a context full of failures. Effective and blunt — you also drop everything useful from that session.

`/compact` to keep the session sharp. Helps with the long-session mechanism by compressing conversation so the model can continue. Compaction is lossy by definition, though, so it can also be the thing that drops your correction.

Turning the correction into code. Underrated, and for a specific class of correction it's simply the right answer — more on this below.

A running notes file you paste from. Works because it's external and durable, but you're the retrieval system, deciding each session which corrections are relevant and pasting them in.

Sort your corrections into two piles first. This is the step that makes the difference.

Pile one: corrections that can be mechanized. "Always cd to backend/ first." "Always rebuild dist after changing App.jsx." "Commit before deploying." Every example in that GitHub issue is in this pile — and for these, the honest recommendation is not a memory layer. It's an npm script that cds for you, a Makefile target that rebuilds, a pre-commit hook, a CI check that fails on an uncommitted deploy. A rule an agent can't violate beats a rule it's supposed to remember, and it protects you from your own future self too. If you take one thing from this piece, take that.

Pile two: corrections that can't be mechanized. "We allow that pattern in the adapter layer because upstream returns 200 on failure." "The client rejected the modal approach in March." "Don't refactor the legacy importer, it's being replaced in Q4." No script enforces judgment. These are the ones that need to be written down somewhere durable, kept short, and surfaced when relevant — and this is where an external memory layer does real work: the correction lives outside any one session, it's retrieved when the topic comes up rather than loaded on every request, and it stays short enough to actually compete for attention.

MemoryLake is built for pile two — one store your agents read from over MCP or the API, holding the decisions and constraints your work produced instead of accumulating them in an instructions file that gets longer every week.

The boundary needs stating plainly, because #37314 is exactly the case that proves it: a memory layer does not guarantee the model complies. Whether an agent acts on what it reads is model behavior, and no storage system controls that. What changes is availability and shape — the constraint is present, current, and short at the moment it's relevant, instead of missing entirely or buried at line 180. That's a real improvement and it is not a guarantee. Anyone telling you otherwise is selling.

Step 1: Create an API key

Generate a key and make your first request in about 30 seconds. Keep it in your environment or a secret manager rather than in a config file you might commit.

Step 2: Upload your first memories

Drop in the documents, images, and files that hold your pile-two corrections: the decisions doc with its reasons, the architecture notes, the "we tried this and it failed because" writeups. Upload the sources rather than a tidy summary — the reason behind a correction is usually the part that gets summarized away, and the reason is what stops it being re-litigated.

Step 3: Connect your AI & agents

Give Claude, Codex, OpenClaw, and other AI agents access to memory via MCP or the API. Claude Code supports MCP servers, so this is a configuration entry. The same store is then readable from your other agents, which matters because corrections don't stop being true when you switch tools.

The most immediate change is that your CLAUDE.md stops growing. Mechanizable rules become scripts and hooks; judgment-shaped corrections move to the store. What's left is a short file of standing rules the model can actually attend to — which is the fix for the attention problem, not a workaround for it.

The second is that the fifth repetition stops. Not because the model became more obedient, but because the two categories are now handled by mechanisms that suit them: the build-order mistakes can't happen, and the judgment calls are retrievable instead of remembered.

The third is that corrections survive the session boundary in a form you can audit. When something is wrong you edit one record rather than hunting for where you wrote it — and you can see whether a correction was ever captured at all, which is usually the answer.

And they survive the tool. "Don't refactor the legacy importer" is true in Cursor and Codex too. Kept in CLAUDE.md, it's a Claude Code fact; kept in a shared store, it's a project fact — the same reason adding a memory layer to Claude Code tends to outlive whichever agent you're using this quarter.

Mechanize anything mechanizable

Before writing a correction down, ask whether a script, hook, or CI check could make it impossible to get wrong. If yes, do that instead. Every example in the reported case above was mechanizable, and the reporter updated memory five times rather than adding a one-line npm script. That's not a criticism of them — it's the trap the whole workflow sets, because writing a rule feels like the same kind of action as writing code.

Write the trigger, not just the instruction

"Use snake_case for database columns" is weak. "When adding a migration in db/migrations/, use snake_case for column names — the ORM mapping assumes it" gives the model a condition to recognize and a reason not to second-guess. Corrections that name their trigger survive better than corrections stated as bare preferences.

Keep the always-loaded file short on purpose

Every line in CLAUDE.md is loaded on every task and competes with every other line. Treat it as a scarce resource: standing rules only, capped at something you'd re-read yourself. Everything else belongs in retrieval. A long instructions file isn't more thorough, it's less effective — and the long-session attention problem makes that worse, not better.

Stop after two failed corrections and change approach

If a correction hasn't taken twice, the third repetition won't fix it. Either mechanize it, move it into a short retrievable record, or clear the session and start fresh. Repeating a correction into a context already full of that correction failing is the least effective option available.

Commit the fix before moving on

The marmot.svg case in that issue is worth internalizing: the correction was applied, then lost because it was never committed. Some "it forgot" is really "it was never persisted anywhere," and that includes git.

Claude Code forgets your corrections for two different reasons and the fixes aren't interchangeable. Usually the correction was never written anywhere durable, so there was nothing to remember. Sometimes — as a March 2026 report on the claude-code repository documented, with memory files updated five or more times for the same issue and the reporter concluding that the memory system "captures knowledge but doesn't reliably influence behavior" — it was written down and still didn't happen.

So split them. Mechanize what a script or hook can enforce, because a rule that can't be violated beats a rule that has to be remembered. Put the judgment-shaped corrections in a store that keeps them short, current, and retrievable at the moment they apply, and keep your always-loaded instructions file small enough that the model can actually attend to it. That combination handles both failure modes. Neither one alone does.