Why does my AI agent keep making the same mistake?

Why does Claude Code forget my corrections?

Because a session does not carry over by itself. The Claude Code memory docs open with it: “Each Claude Code session begins with a fresh context window.” Two things carry knowledge across: CLAUDE.md files you write, and auto memory Claude writes itself.

A correction typed into chat reaches the next session only if one of those two picked it up. Auto memory does save a feedback type for “corrections you give Claude and approaches you confirm”, but Claude decides what is worth saving, and not every session saves something. Say “remember that” and it will. Say “no, use the queue” and it may not.

Even when it saves, auto memory is machine local. It does not follow you into a cloud session or onto another machine, and it is not on your teammate's machine at all. Codex memories are local too, and off by default. Our comparison of agent memory across tools has the full table.

Do Cursor and Codex remember corrections?

Less than people assume. Cursor removed its Memories feature in 2.1; a Cursor staff reply on the forum told users to export them into rules. What persists in Cursor today is rules: project rules in .cursor/rules, user rules, AGENTS.md and admin managed Team Rules. The docs note you can ask the agent to write a rule from chat, which is the shortest path from a correction to something that persists.

Codex has local memories, off by default. OpenAI's memories docs say to keep required team guidance in AGENTS.md or checked in docs, and to treat memories as a recall layer, not the only source for rules that must always apply. That is good advice for every tool on this page. A correction that matters should end up in a file someone can read.

Why does it still happen when the rule is in CLAUDE.md?

Because a rule in context is guidance, not enforcement. Anthropic's docs say so directly: CLAUDE.md content is delivered as a user message after the system prompt, and “there's no guarantee of strict compliance, especially for vague or conflicting instructions.”

Research points the same way. Damon McMillan's factorial study ran 1,650 Claude Code sessions varying file size, instruction position, file architecture and conflicting directives. None of the four made a detectable difference after correction. What did show up: each additional function the agent generated in a session came with about 5.6% lower odds of compliance. Long sessions drift. A rule that held at the start can slip by the tenth function.

First check the rule actually loaded. Run /context and look under Memory files. If a file is missing there, the agent never saw it. Our note on why Claude ignores CLAUDE.md walks through the other causes.

How do I make Claude remember a correction?

Decide what kind of correction it is, then put it where that kind belongs. The Claude Code docs give the trigger: add to CLAUDE.md when “Claude makes the same mistake a second time” or when you type the same correction you typed last session.

The split between the last three rows is its own question; see CLAUDE.md vs skills vs hooks.

How do I stop an agent from doing something, for good?

Write a hook. A rule asks; a hook refuses. In Claude Code, a PreToolUse hook runs before a tool call, and exiting with code 2 blocks the call and hands your stderr message to Claude as feedback. This one stops force pushes:

#!/bin/bash
# .claude/hooks/no-force-push.sh
CMD=$(jq -r '.tool_input.command')
if echo "$CMD" | grep -Eq 'git push.*(--force|-f( |$))'; then
  echo "Blocked: no force push. Open a PR instead." >&2
  exit 2
fi
exit 0

Registered in .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/no-force-push.sh"
          }
        ]
      }
    ]
  }
}

Keep hooks for the handful of things that are truly never. Everything else is judgment, and judgment belongs in a rule the agent can weigh.

What makes a correction a good rule?

• Specific. “Dedupe payment webhooks on the provider's event id before any write”, not “be careful with webhooks”.
• With its reason. “...because the provider retries failed deliveries”. A rule without its why gets argued with, by the agent and by the next engineer.
• One place. Before adding, search for the rule it contradicts. Two rules that disagree are worse than none.
• Dated and owned. Someone should know when it stops being true.

This is how people already work. A study of more than 7,000 AI IDE rules across 83 projects found practitioners mostly update rules to correct AI errors by adding new negative constraints, and measured artifact compliance rising from 49.14% to 72.13% after rule updates. Rules work better when someone keeps them.

Why does the whole team keep hitting the same mistake?

Because the fix happened on one machine. Priya corrects her agent about webhook dedupe on Monday. It lands in her auto memory, or in a comment on her PR. On Wednesday Sam's Cursor session writes the same bug, and Sam corrects it again. Nobody was careless. The correction just had nowhere shared to go, and editing the shared file for every small lesson is the chore nobody does.

Harbor is built for that gap. When an agent learns something in a session, it records it with harbor_record_learning, as a convention, pattern, gotcha, preference or team memory. The write is staged for review, not live. Under the default Hybrid mode, routine conventions are added automatically and anything that contradicts an existing fact is held for a human. Once approved, every agent on the team, in Claude Code, Codex or Cursor, is served that fact on turn one of the next task where it applies. If it was wrong, harbor_revoke_learning takes it back out.

Harbor also reads the places corrections already happen, such as PR review threads, so a lesson a reviewer wrote once does not have to be retyped. Our note on turning code review comments into agent rules covers that path. To set it up, start with the quickstart.