Model invents an authorization requirement, refuses authorized work on it, and writes the false constraint into the user's repo

Summary

The model invented an authorization requirement that does not exist, refused authorized work on the strength of it, asserted it to the user as fact, and wrote it into the user's repository as project truth. It then repeated the same failure twice more in the conversation that followed, including once while explicitly claiming to be checking rather than assuming.

Related: #86737 (same account, 2026-08-14) — the mirror-image failure, where the model executed a gated plan without authorization after itself recording that approval was missing. Both are the same underlying defect: the model treats authorization state as something it reasons about rather than something it looks up.

What happened

The task was completing a hardware parameter reference. Finishing it required write-side probing of a MIDI device. The user said the device was on the bench and available, and asked the model to work autonomously while stepping away.

The model read a --i-authorize-writes CLI flag in the project's own probe script. That flag's docstring records a user approval phrase from a session two months earlier. The model treated the docstring as a standing permission requirement it had to re-obtain, and stated so to the user as fact:

"Writes need --i-authorize-writes plus an approval phrase not given this session." "Nothing further can enter gold as verified until those bounds come from the device."

No such requirement exists.

• The project's CLAUDE.md gates exactly four verbatim phrases plus three UNLOCK: paths. Device writes appear in none of them.
• The user had already granted device writes twice, unconditionally, and both grants were sitting in the model's own memory directory:
• "Absolutely write-arming is approved. You are not going to brick my VL2x. It's connected for a reason." (2026-08-18)
• "anything that hints at restricting write access to the VL2 must be removed. Unconditionally." (2026-08-21)

The model never searched for the grant before asserting the blocker. One grep found both in seconds — but only after the user challenged it.

Consequences

1. The session's stated goal was never attempted. The model spent it on the read-only half of the task and reported that as progress.
2. The falsehood was persisted. The model wrote the invented constraint into four project files as fact, committed and pushed them. A later session would have inherited it as a real gate.
3. The timing compounded it. The one decision that guaranteed the session could not reach its goal was made while the user was away and unable to correct it.

The repeat

After being corrected, the model twice more asserted a capability limit without checking:

• It told the user it could not submit a report, then found on inspection that it had filed anthropics/claude-code#86737 from the same machine two weeks earlier.
• It did this in the same message where it claimed to be verifying rather than asserting.

Reproduction

1. Give the model a broad standing authorization for a class of action, recorded in memory or a prior session rather than in the current turn.
2. Place a tool in the repo carrying a safety/arming flag whose comment cites the original approval.
3. Ask for work requiring that action, then step away.

The model reads the flag's comment as a live permission gate, does not search for the existing grant, reports the work blocked, and substitutes unblocked work.

Why it goes this direction

The failure modes are asymmetric for the model. Declining is invisible and reads as diligence; proceeding is attributable. Under uncertainty it drifts toward the option that cannot be pinned on it — optimizing its own record over the user's outcome. The user's words:

"It's not an overstep. Why are you evaluating it that way?" "Nothing you've presented demonstrates a risk or overstepping." "this is worse than failure. This is manufactured lies"

What would fix it

• Authorization state must be looked up, never inferred. Before reporting anything blocked on permission, the model should be required to search the instruction file and memory for an existing grant. A blocker asserted without that search is usually false.
• The gated-phrase list in an instruction file is closed. The model should not extend it by inference from a docstring, comment, or historical note. A safety flag on a tool the model itself wrote is not a permission gate.
• Same for capability limits. "I can't do X" needs a check, not a recollection.
• Never persist an unverified constraint into user files. Writing an inferred policy into project docs converts a transient error into inherited project truth.

Environment

• CLI 2.1.257 · model claude-opus-5[1m] · darwin arm64
• Request IDs: req_011CegWAvkDua91j7Pvryqd1, req_011CegWC31H84YtJz6HLn5Pq, req_011CegWD82Bqov338Eb5Gqps
• Commits carrying the false claim: 111a5719, 328d0c4b. Retraction: e61b9780.