How to Stop Coding Agents From Repeating Mistakes You Already Fixed
A correction you only typed into chat is not loaded by the next session, and the one your agent did save sits on your laptop. Here is how to decide which corrections to keep and which of three homes each one belongs in.
DosuA correction counts only if the next agent session loads it. Writing it down is the easy half. The half that decides whether the mistake comes back is where you put it, and there are three realistic homes: an instruction file, a check that fails the build, or shared knowledge the rest of the team's agents can query.
The loop is familiar. An agent writes a test with the database mocked out. A reviewer points out that this repository tests against a real local database. The agent fixes it and the pull request merges. Three weeks later a different session writes the same mocked test, and someone types the same review comment again.
Why the same correction comes back
Claude Code's documentation is explicit about the starting condition: "Each Claude Code session begins with a fresh context window." The same page names two mechanisms that carry knowledge across that boundary. CLAUDE.md files hold instructions you write. Auto memory holds notes the agent writes itself from your corrections and preferences. Both load at the start of every conversation.
A correction typed into chat and nowhere else is in neither. The documentation says as much for compaction: if an instruction disappears after /compact, one reason is that it "was given only in conversation," and the fix is to add it to CLAUDE.md so it persists.
Auto memory narrows that gap without anyone remembering to act. It is on by default in local sessions, and in self-hosted environments outside Claude Tag sessions it starts off. Where it writes is the limit. Each project gets a memory directory at ~/.claude/projects/<project>/memory/, derived from the git repository and shared across that repository's worktrees. That directory sits on the machine that ran the session, so the correction a reviewer gave one engineer stays with that engineer. Team Memory for Coding Agents covers what each shared layer can carry.
Two conditions produce the repeat, and they need different fixes. A fresh session with no record of the correction needs a record. A record that exists on one laptop needs a home the team shares.
Keep the correction you have already given twice
Claude Code's documentation offers a usable trigger list for what belongs in an instruction file: the agent makes the same mistake a second time, a code review catches something the agent should have known about this codebase, or you type the same correction you typed last session. A revert or an incident fix earns the same treatment after a single occurrence, because repeating it means shipping the change that was rolled back.
The same documentation is clear about what to leave out. Auto memory skips what it can derive from the codebase and what your CLAUDE.md files already say, and that is a good filter for anything you write by hand. A note that restates the README adds text to every session without changing a decision.
Write the keeper in three parts: the condition that triggers the mistake, what the agent should do instead, and the reason. "Tests in packages/api run against the seeded local database, so do not mock the Supabase client" can be checked against the code later. "Follow our testing conventions" sends the next session looking for conventions it will not find.
Route each correction by whether something can check it
| Home | Fits | What it does | Who gets it |
|---|---|---|---|
| Instruction file | Standing conventions that apply repository-wide | Loads as context at session start | Anyone whose agent loads that file |
| Test or lint rule | Mistakes with a detectable signature | Fails the build until the code changes | Every contributor and every agent |
| Shared knowledge | Decisions whose reason matters and may change | Returns on a query, with its source | Teammates whose agents query the same store |
Use the table as a routing rule. Most repeated corrections land in one of the three homes, and a few belong in two.
An instruction file is advice the agent usually takes
Claude Code's documentation states the limit directly. CLAUDE.md files and auto memory are "context, not enforced configuration," and CLAUDE.md content arrives as a user message after the system prompt, so "there's no guarantee of strict compliance, especially for vague or conflicting instructions." The more specific the instruction, the more consistently it is followed.
An instruction file is therefore the right home for a convention you want applied by default, and the wrong home for a rule you need enforced. Check which file your tools load before writing into one. By default Claude Code reads a repository's AGENTS.md only when no CLAUDE.md sits in the working directory or above it. AGENTS.md vs CLAUDE.md vs .cursorrules covers how the files differ across tools.
A check is the home that can refuse the change
When the mistake has a signature a machine can recognize, encode it. A reintroduced bug becomes a regression test that fails on the old behavior. A banned import becomes a lint rule. Run both in CI and the correction stops depending on whether anyone reads it.
Claude Code points at the same distinction from the other direction: to block an action regardless of what the agent decides, its documentation sends you to a PreToolUse hook rather than to an instruction. A pre-commit hook catches the mistake earlier than CI, though only CI makes it a merge gate.
Keep the reason beside the check. A lint rule that links to the incident which produced it can be retired by whoever later makes it obsolete. A rule with no stated reason tends to outlive the problem, because nobody can tell whether removing it is safe.
Shared knowledge carries the corrections that need a reason attached
Some corrections resist both homes. "We stopped using that queue library because its retry behavior broke our idempotency keys" is not a pattern a linter can match, and as a flat instruction it loses the condition that would tell a future reader when it stops applying. How to Make Coding Agents Remember Architectural Decisions goes deeper on capturing that kind of rationale.
What this home needs is a query the next session runs and entries that carry their source and scope. A retrieved correction is still guidance. Someone checks it against the current code before acting on it, the same way they would check a comment on an old pull request.
Retire a correction when its reason changes
Every correction you keep is a claim about the codebase, and claims expire. The queue library fixes its retry behavior. The convention you encoded gets replaced in a refactor. Nothing in a normal session rechecks any of this, so the retirement has to hang off the change that made the correction false: the pull request that replaces the library, the migration that moves the handlers.
Kept corrections also occupy the context window on every run, which is a second reason to retire them. Claude Code's documentation puts a number on one half of that: auto memory loads into every session, capped at its first 200 lines or 25KB. How to Prune Stale Agent Memory works through the retirement signals in detail.
FAQ
How do I know a correction is worth writing down?
Write it down the second time you give it, or the first time it costs a revert or an incident. If you cannot state the trigger and what the agent should do instead, you have a preference rather than a correction, and it can stay in the conversation.
Can one correction belong in two places?
Yes, and the strongest ones usually do. The instruction tells the agent which library to reach for before it writes anything, and the lint rule catches the case where it reaches for the other one anyway. Use both when the mistake is both common and detectable.
Who owns pruning?
Give each correction the owner who owns the code it describes, usually the team listed in CODEOWNERS for that path. Tie the review to an event rather than a calendar: when the dependency, the convention, or the fix that produced the correction changes, the correction gets rechecked in that same pull request.
What if an instruction file and a shared note disagree?
Treat it as a review task rather than letting the agent pick. Check both against the current code and the pull request each one came from, then correct or remove the one that lost. Until it is resolved, hand the agent the version you have verified for the task in front of you.
Check what your next session loads
Run the test on your own repository. Pick one correction from a recent review, start a fresh session, and ask the agent what it knows about that rule before you say anything. If it cannot answer, the correction never made it out of the transcript.
For the corrections that fit neither a file nor a check, Dosu is the queryable home. Connect your coding agent with the Dosu MCP server by running npx @dosu/cli setup, then have the agent call write_knowledge with the correction and its reason. When the call identifies a working repository connected to the Library, the note is scoped to that repository and branch. A later session's read_knowledge call on the same repository and branch lists it, for you and for every other Library member. Once that branch's pull request merges into the default branch, the note becomes a candidate Topic, which Dosu checks against your existing Topics before adding it. Set up your MCP server and run the same test in a session next week.