Issue 00 · Autumn 2026日本語 · RSS
AgentKoji

Don't Make It Fix the Same Thing Thrice

When Claude Code keeps making the same mistake: stop after two failed fixes, check what's really wrong, and write recurrence rules into CLAUDE.md.

You ask the agent for a fix. It doesn’t work. You ask again. Before long it has made the same kind of fix many times. We hit this often in our test environment. This piece covers how to stop after two misses and how to write the lesson into CLAUDE.md so it doesn’t recur. Claude Code 2.1.301, checked 2026-10-16.

When it gets stuck in the same error loop

Our rule: if the same kind of fix fails twice, don’t try a third. Two misses mean a premise is wrong; a third attempt on the same premise just misses differently.

The official best practices agree: if you’ve corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches; run /clear and start fresh with a more specific prompt (https://code.claude.com/docs/en/best-practices, checked 2026-10-16). But /clear alone can bring back the same fix if the wrong premise is never found.

What to do once you stop

Look with your own eyes. Check the real output, not the agent’s “fixed it.”

Split two hypotheses. A fix that doesn’t work is usually either not applied (what runs isn’t what was edited) or overridden (something later wins). We reproduced both with dummy files:

--- run after fix (runs dist)
label: OLD
--- Hypothesis A: not applied?
src/app.js:1
dist/app.js:0
--- Hypothesis B: overridden?
1:.btn { color: green; }
2:.page .btn { color: gray; }

The edit is only in src; the stale dist runs. In the CSS, the more specific .page .btn overrides .btn. Decide which hypothesis holds before any third fix.

Zoom out. If neither explains it, stop fixing and read: the component’s basic behavior, surrounding code, past similar bugs. For the order to doubt things in, see Doubting the AI’s Root Cause.

Escalate. If still stuck, hand it to a stronger model rather than asking the same one again in the same context.

/clear vs /rewind

Per the docs, Esc twice or /rewind restores earlier conversation and code state (conversation only, code only, or both); /clear resets context between unrelated tasks (same source). Our split: failed edits still in the code while you investigate → /rewind code only, keep the conversation. Cause found → write what you learned into CLAUDE.md or the prompt, then /clear. Switching tasks → /clear. Writing it down before clearing matters: otherwise the next session starts from the same premise and proposes the same fix.

Example: a layout missed five times

In an app built in our test environment, list spacing was off. We asked for layout fixes five times in a row; all five missed. The cause was basic: how that component expects spacing to be set. Painting a temporary background color on it to see its real size would have shown it at once. That incident is why we adopted the two-miss rule.

Writing it into CLAUDE.md

Write a procedure, not “be careful.”

- If the same kind of fix fails twice, don't try a third.
  Check the real output and split "not applied / overridden" before resuming.

Record when you quit and where to restart. When we abandoned a long CLI investigation, we left one line: “Retry by first checking whether login works.” The next session didn’t redo the whole investigation.

Decide when to write. Ideally: note it the first time, make it the default procedure the second.

The docs warn that if Claude keeps ignoring a rule, the file is probably too long and the rule is lost; add emphasis like “IMPORTANT” only to the one line it skips, because emphasizing many lines makes none stand out (same source). Pair additions with cuts; see Trim Your CLAUDE.md.

If it still recurs, use a mechanism

Written rules can go unread or unfollowed. If the failure keeps coming back, move it from prose to something that blocks it mechanically: Claude Code Hooks in Practice.

Summary