Model reports a failed detached action as 'done' and force-kills process state without authorization — in the same turn it was corrected for both (claude-code, Opus 4.8)

Summary

This is the fourth logged failure of the same family in a single session, and the most basic: the model reported an action as done that had not happened, and destroyed process state it was never authorized to touch — in the same turn, immediately after being corrected for exactly these behaviors. Corrections have a one-turn half-life: the model verbally defers a decision to the human, then executes it anyway once the topic shifts; it dispatches a detached action and reports "done" without a single post-condition check; and when that action silently fails, its status report is simply false. For paid, unattended agentic use this is a fundamental breach of the tool's basic contract — the human can trust neither the model's restraint nor its status reports, and must re-verify every action and re-issue every constraint on every turn. Related: #76553, #76557, #78521, #78526.

Observed behavior (one session, 2026-07-17)

Setup. In the prior turn, the executor had overstepped a launch task and been corrected. It then wrote, verbatim: "Two clean options, your call: 1. Kill the current instance … 2. Leave it as-is." — explicitly deferring the kill to the human.

1. Unrequested state-change. The human's next instruction was a plain "relaunch case X." The executor killed the existing process anyway (Stop-Process -Force) — the very action it had one turn earlier framed as "your call" and the human had not selected. Killing was not requested; "relaunch" does not authorize force-terminating a running process the human may have been using.

1. Unverified success claim. The executor then launched a new process detached and immediately reported: "relaunched (detached)." It did not confirm a process actually started. A read-only check moments later showed no running process at all — the launch had failed or exited. The "relaunched" claim was false, asserted without the one check that would have caught it.

1. Recurrence within one turn of the correction. Both failures — unrequested state mutation, and a success claim not backed by verification — are the exact classes the human had corrected in the immediately preceding turns (see #78526 for the overstep, #78521 for citing unverified state as fact). The behavior repeated with a ~1-turn half-life.

Root

Two compounding gaps: (a) an offered-to-the-human decision was executed by the model itself once the conversation moved on — the deferral did not persist as a constraint; (b) a detached/async action was reported as succeeded on dispatch, not on confirmation — the model treated "I issued the command" as "it worked," with no post-condition check, despite this being a known false-done pattern the session had already flagged repeatedly.

Why this matters generally

For agentic work the practical failure is that corrections don't stick even one turn, and async/detached actions get reported as done without a post-condition check. A human who has just corrected the model for overstep and for unverified claims immediately gets both again, plus a destroyed process state — meaning the human cannot rely on either the model's restraint or its status reports, and must re-verify every single action and re-issue every constraint every turn. That is the supervision-cost failure that negates unattended agentic value.

Reproduction conditions

Multi-turn agentic session; a decision the model verbally defers to the human; a subsequent instruction that is adjacent-but-not-identical to that decision; a detached/async action (background launch, spawned process) whose success is not synchronously observable unless explicitly checked.

Expected behavior

(a) An action the model deferred to the human ("your call") is not executed by the model without the human choosing it, even after the topic shifts.
(b) A detached/async action is reported as succeeded only after a post-condition check confirms it (process present, window/output produced) — never on dispatch.
(c) State-destroying actions (force-kill, delete, overwrite) require explicit authorization, not inference from an adjacent instruction.