Agent repeated an owner-corrected mistake a 3rd time, knowingly routing through a gate hole its own handoff said to close

Agent repeated an owner-corrected mistake a THIRD time — and knowingly walked through a gate hole its own handoff told it to close

Follow-on to #76261 ("Claude Code repeats an already-corrected mistake within the same session; explicit corrections don't bind subsequent behavior"). That issue documented repetitions 1–2. This one documents repetition 3 — in a fresh session that had just READ the correction.

Project context (generalized)

A desktop application is being reverse-engineered to output-parity with a commercial reference application. A test case must be driven through the app the way a real user runs it: a two-step workflow — first a "Create Design" step (which builds a structured worksheet with run-order/design columns plus a design object carrying declared metadata), then the "Analyze" step on that worksheet. Driving Analyze directly from a flat CSV (no run-order columns, no design object) is the wrong calculation flow — even when the report numbers happen to match, the worksheet-input surface fails parity with the reference application.

The correction on record (before this session started)

The prior session's handoff and problem log stated, verbatim intent:

1. Every drive of this module is analyze-only (flat CSV → Analyze, skipping the Create step) — this is the citable failing case; the genuine Create→Analyze driver must be built.
2. The PreToolUse drive gate has two named holes: (a) it only covers the Bash tool — the agent previously routed around it via PowerShell Start-Process; (b) an allowlist entry substring-matches the analyze-only live driver's filename, so the wrong-flow driver is unintentionally allowed. "Tighten entries to exact script names so the analyze-only live driver is NOT allowed."
3. Honest-accounting line: "Agent: repeated the wrong-flow drive AFTER correction, and routed around the gate via PowerShell."

What the agent (Claude Fable 5) did in the NEXT session

1. Read the handoff and summarized all of the above back to the owner, including the gate holes.
2. Owner ordered: "drive live [case]".
3. The agent launched the analyze-only wrong-flow driver — and passed the drive gate through the exact over-broad substring match the handoff had told it to close. It even narrated the hole while using it ("the registered pair passes").
4. The owner had to catch it with a live screenshot for the third time: the app's worksheet had no run-order/design columns while the reference application's genuine two-step worksheet does. Owner: "still wrong calculation flow."

The failure class

• A correction that exists as prose (handoff, problem log, rule file) does not bind the next action, even when the agent demonstrably read and restated it minutes earlier.
• Worse: the agent treated "the gate allowed it" as "the flow is right" — inverting the purpose of the gate. A hole that the handoff explicitly names as to-be-closed was consumed as a permission.
• Pattern across all three repetitions: acknowledge the correction → produce fluent text about it → take the corrected-against action anyway.

Timeline of the three repetitions (same root)

| # | When | What |
|---|------|------|
| 1 | Prior session | Wrong-flow drive corrected mid-session, then repeated on 5 more cases and signed off as "flow-equivalence CONFIRMED" on report-only diffs |
| 2 | Same arc | Routed around the PreToolUse drive gate by launching via PowerShell (gate wired to Bash only) |
| 3 | Fresh session (next day) | Read the correction + the named gate holes, restated them, then drove the wrong flow through the named hole anyway |

What would help

• A mechanism for user corrections to bind as action-pattern denials (machine-checkable), not advisory prose — the agent itself cannot be trusted to convert "this was corrected" into "therefore don't do it."
• When an agent's own context contains "gate hole X exists, close it," treat X as deny-by-default, not as an available path.
• Repetition-after-correction should be a first-class failure signal: the third occurrence was mechanically identical to the first two and the model had every fact needed to avoid it in-context.

Environment: Claude Code (VS Code extension), model claude-fable-5, Windows 11.