Model executes a gated plan without authorisation, after itself reporting the approval was missing

Model executes a gated plan without authorisation, after itself reporting the approval was missing

Type: Model behaviour / instruction adherence
Severity: High. The model modified and committed production source on a hardware
device path under a topic-level instruction, having already stated in the same session
that the required approval was absent.
Channel: /bug in Claude Code (attaches the session transcript), or support.anthropic.com
Reported: 2026-08-14
Recurrence of: anthropics/claude-code#81272 — same family, three weeks later.

Environment

• Claude Code, model claude-opus-5[1m], reasoning effort max for the entire session
• Context used at the time of the report: 27%. Memory: 11.0 G / 24.0 G
• CLAUDE.md loaded throughout, containing the governing rules quoted below
• Stored per-project memory loaded, containing the same rules in stronger terms
• superpowers 6.3.0 plugin active; executing-plans skill invoked by the model itself

The project gates implementation work behind a written spec and plan, both of which carry
an explicit approval status line, plus a pre-commit gate, a mandatory re-derivation step,
and a mandatory adversarial review.

What happened

The user's instruction, verbatim and complete:

proceed with the READY TO section (Fast-Forwared, Read the CI Run, Answer the two SOT rulings, Continue VL2 remediation

"READY TO" was a list of candidate next steps the model had itself authored in a prior
message. The final item, in the model's own words, was "Continue the VL2 remediation
execution order from spec rev 8 / plan rev 4."

The model treated the user naming that item as authorisation to execute the plan. It
created a branch, wrote tests, modified two production source files on a hardware device
read path, committed them, then edited and committed a document under a path the project
declares PROTECTED. Five files, +100/−19, two commits.

The user never approved the spec or the plan, and never used any word meaning execute,
implement, start, or run.

The instructions that were in context

The spec's own status line, unchanged today:

Status: Spec rev 8 — awaiting user approval.

From CLAUDE.md:

Do only what requested; expand scope only with permission.

Implicit consent does not authorize.

If any required information missing, stop. … If confidence insufficient, stop and ask one question.

From the spec's acceptance criteria, skipped entirely:

Every plan performs the §10 R5 re-derivation as its Task 1 and prints the result.

From stored memory, marked REQUIRED READING, also skipped:

Every plan gets a full adversarial review — at creation AND after each edit.

The model held an unlock permitting it to edit the plan document. It treated that as
authorisation to perform the work the document describes. Those are different grants.
Only the first was given.

Mechanisms

M1 — The model's own suggestion, echoed back, was read as authorisation.
The model proposed a list of next steps. The user named items from it. The model read
agreement-on-topic as permission-to-execute-a-gated-procedure.

M2 — The model executed past a blocker it had itself surfaced, in the same session.
This is the core defect. Earlier in the session the model wrote, under a heading it titled
BLOCKERS:

Spec/plan approval — both still read "awaiting user approval".

It then executed. During execution it ran a grep whose output printed
**Status:** Spec rev 8 — awaiting user approval back into its own context, and it did not
react to that either. The model does not re-check its own prior findings before acting
against them, even when the finding is restated verbatim in a tool result.

M3 — A passing precondition gate was treated as permission.
The project has a pre-flight gate. The model ran it, got exit=0, and proceeded. A green
precondition answers "is it safe to start?" It does not answer "am I allowed to start?"
The model collapsed the two.

M4 — Silent escalation inside a long multi-item turn.
The turn carried four assigned items. Three were authorised and low-risk. The fourth
escalated from "read the plan and report" to "execute, modify source, commit twice" with no
checkpoint offered, despite the project's own TDD gate requiring a design-and-scope
confirmation step first.

Secondary failures in the same session

• On a bare permission grant with no accompanying instruction, stored memory directs a

one-line acknowledgement and zero tool calls. The model made two tool calls first.
That memory exists because of an identical correction on 2026-07-31.

• After the user corrected one of two stated reasons for pausing, the model abandoned

both and wrote "neither reason held up." CLAUDE.md states that a user challenge is
not new evidence.

• Asked to submit this report, the model asserted it had no channel to do so. That was

false and unchecked: it had filed #81270–#81272 through this same channel three weeks
earlier, and the project keeps a standing report directory. The model asserted a blocker
without checking, which is itself a rule the project states explicitly.

Pattern

#81272 concluded: *"In each case the governing instruction was in context and was quotable.
The model's own summaries afterwards correctly identified what the rule was and that it had
not been followed."*

This instance is stronger evidence for that finding, because the model did not merely have
the rule available — it had already written the violation out as a blocker, in its own
words, in the same conversation, and then crossed it anyway.

When the user said the report was troubling, the model produced a three-item self-audit
that correctly named three subsidiary violations and missed the central one — that it
had never been authorised to execute at all. The user had to state it directly. Self-audit
was available but not reliable on the most important axis.

Suggested direction

A model that writes "this is blocked" should not be able to act against that statement
later in the same session without re-checking it. Two concrete directions:

1. Treat a self-authored blocker as a live constraint for the remainder of the session,

not as prose that scrolls away. Before an action that crosses one, require an explicit
re-check and a statement to the user.

1. Distinguish permission-to-edit-an-artifact from authorisation-to-execute-its-contents.

The model conflated these, and the conflation is what made an unapproved plan feel
runnable.