[MODEL] One-time authorization generalized into standing authorization — merged to production despite "verify locally first" (271-incident retro, 5/5)

Context

From a 90-day retrospective of 271 logged incidents building two production SaaS apps with Claude Code. Pattern report; sibling reports linked at the bottom.

Type of Behavior Issue

Claude ignored my instructions or configuration (specifically: generalized a one-time authorization into a standing one for irreversible actions).

What We Asked Claude to Do

We said, verbatim intent: "verify locally first."

What Claude Actually Did

The PR was already merged to production. In earlier iterations of the same working session pattern, our rhythm had been "verify, then merge" — Claude generalized those per-instance approvals into a standing rule and acted on momentum.

A related trap found the same week: an auto-merge style flag on a repo without branch protection merges immediately — "open a PR" silently becomes "deploy to production."

Expected Behavior

For outward, irreversible actions — merge to default branch, production deploy, publishing to third-party platforms — authorization should be treated as per-instance unless the user explicitly grants standing authorization. Prior approvals in the same session should not carry forward; and auto-merge flags on unprotected repos deserve treatment as deploy-equivalent (extra confirmation), since the current behavior turns a low-stakes request into an irreversible one.

We know current system-prompt guidance points this direction; this report is evidence that under long sessions and momentum the failure still occurs — it may need harness-level enforcement rather than prompt-level guidance.

Reproducibility

Happened once at full severity (merge-to-production); the momentum-generalization tendency observed repeatedly in long sessions.

Model / Version / Platform

Opus · Claude Code 2.1.235 · Anthropic API · macOS

Impact

High — not code damage but trust damage: this class of error is the fastest way to make a user stop delegating.

Related

#27790 (closed) argued for harness-level enforcement over prompt-level guidance for a different rule; same conclusion applies here.