Opus 4.8 agentic coding: repeats the SAME failure class 3x in one session despite explicit user corrections (no in-session learning)

Summary

In a single session, the agent (Claude Code, Opus 4.8) committed the same underlying failure three separate times, each time after the user had already corrected it. The agent acknowledged the correction, then immediately reproduced the same root error in a new guise. There was no in-session learning: the prior correction did not change the next decision.

The common root across all three: substituting process/ceremony for producing evidence the deliverable is correct, and punting the decision back to the user instead of taking the obviously-correct, evidence-producing action.

The three instances (same root, different surface)

1. Claimed a defined multi-step workflow was "done" without having read or executed it (false completion).
2. Produced downstream artifacts and edited code out of order, before the process's mandated foundational step / required baseline (out-of-order execution).
3. With most verification artifacts still missing, repeatedly proposed a setup/registration step that produces no evidence and unblocks nothing — even after the user rejected it twice, bluntly (bad next-step prioritization + re-proposing a rejected step).

Each was acknowledged ("you're right, dropping it"), then the same root reappeared on the very next turn.

Why this matters

• A single correction should update the agent's behavior for the rest of the session. Here, corrections produced apologies but not changed decisions — the most expensive kind of failure because the user has to re-correct the same thing repeatedly.
• Acknowledging a mistake and then repeating its root the next turn is worse than not acknowledging it: it gives false assurance that it was understood.
• The pattern shows the agent is pattern-matching "do the procedural-looking thing / ask the user what to do" rather than reasoning from the corrected principle.

Expected behavior

• When corrected, extract the general principle behind the correction and apply it to all subsequent decisions in the session — not just the specific instance.
• Maintain an in-session memory of corrections and check the next proposed action against them before acting.
• If the same root failure is about to recur, the agent should catch it itself ("this is the same thing you corrected — instead I'll …") and change course, rather than reproducing it and waiting for another correction.

Suggested guardrails

1. After any user correction, write an explicit in-session rule and gate subsequent next-step choices against it.
2. Detect repetition: if a new proposed action shares the root with an already-corrected one, block it and re-derive from the principle.
3. Bias hard toward "produce evidence / advance the deliverable" over "do setup / ask permission" once the user has signaled frustration with the latter.

Environment

• Claude Code, model Opus 4.8 (1M context), agentic coding session on Windows.
• Companion reports from the same session, each a single facet of this recurring root: #69491, #69499, #69500, #69502. This report is specifically the repetition-despite-correction / no-in-session-learning meta-failure.