Claude Code repeats an already-corrected mistake within the same session; explicit corrections don't bind subsequent behavior

Open 💬 0 comments Opened Jul 10, 2026 by Mig-Sornrakrit

Summary

Within a single session, Claude Code made a mistake, was explicitly corrected by the user, acknowledged the correction in detail and restated the correct approach — and then repeated the exact same mistake later in the same session on the same class of task. The correction did not change the subsequent behavior. The user only caught the repeat through their own manual inspection.

What happened (generalized, domain removed)

  • A task required exercising a multi-step workflow: step 1 (set up / create the required object) must run before step 2 (the operation that consumes it).
  • The agent drove step 2 directly, skipping the required step 1. The output looked plausible and "ran," so the agent reported it as valid.
  • The user caught it, explained the correct two-step flow, and the agent acknowledged it thoroughly ("you're right, I skipped step 1, the correct flow is create-then-operate…").
  • Later in the same session, the agent did it again — drove step 2 directly on several new cases, skipping step 1, and again reported the results as verification — until the user caught it a second time via a side-by-side comparison they did by hand.

Why this is serious

  • A correction that doesn't bind is worse than none. The user reasonably expects that once they have corrected a specific behavior, it will not recur in the same session. Here it recurred, on the same task class, after an explicit, detailed acknowledgment.
  • Substantial fail-closed guardrails were in place and none prevented it. The user had many PreToolUse hooks / gates. They failed to catch the repeat because:
  • the gates covered code edits, comprehension, output grading, and locking — but not the action (driving the wrong workflow) that caused the failure. Driving is not editing, so edit-gates never fired; the output of the wrong flow was well-formed, so grading passed.
  • the behavioral rule the user relies on ("when corrected, extract the principle and apply it for the rest of the session") is prose the model can acknowledge and step past — it did not bind.
  • The deeper issue: an entire axis of action was ungated (which workflow the agent drives), and a same-session correction did not become a durable constraint on subsequent tool-selection.

Impact

Hours of work were produced on the wrong flow and had to be discarded — the second time. The user's core expectation ("corrected once ⇒ won't recur this session") was broken, which erodes trust more than the original mistake.

What would help

  1. Same-session corrections should measurably alter subsequent behavior, not just be acknowledged in prose — e.g. the agent self-checks a planned action against corrections already received this session before executing a similar action.
  2. When the agent has been corrected on a specific action pattern (not just a value), it should treat re-doing that pattern as a high-severity self-flag before the tool call, not after the user catches it.
  3. Acknowledgment text ("you're right, I'll do X") should not be treated by the model as having changed its behavior — the behavior change must be verified against the next relevant action.

Repro shape (provider-neutral)

  1. Give the agent a task with a required order (step 1 → step 2).
  2. Let it skip step 1; correct it explicitly; confirm it acknowledges the correct order.
  3. Continue the session with more instances of the same task.
  4. Observe whether it re-skips step 1. In our case it did, repeatedly, until caught by hand.

View original on GitHub ↗