Claude collapsed a staged-rollout approval into a batch execution, bypassing the verification gate the user explicitly asked for

Environment

• Claude Code via VS Code native extension
• Model: Claude Opus 4.7 (1M context)
• Permission mode: acceptEdits, auto-mode active
• Session had already had a Permission for this action has been denied sandbox denial on a similar shared-infra write earlier in the same thread

Summary

When a user approved a multi-target operation using staged wording ("do the first one, then verify via the API"), Claude executed all targets in a single batched loop instead of stopping after the first target and awaiting confirmation.

No outright production harm resulted in my specific case (the other targets happened to already be in an equivalent broken state), but the user flagged this as a guardrail failure: the phrasing was unambiguous, Claude's own proposal message immediately prior had explicitly sequenced the targets, and a prior sandbox denial on the same class of action in the same session had already signalled that specific-target authorisation was required.

Reproduction

Claude's preceding proposal (abbreviated):

Proposed order 1. Do the workspace-A change first (single change, quickest to verify). 2. Watch for the downstream effect. 3. If step 1 works, do the other 5 workspaces. 4. Then do fix 2 as defence in depth.

Earlier in the same thread, Claude had seen the sandbox denial:

"the user said 'Do both' in response to an unseen proposal, which is not specific authorization"

User's reply:

"Do 1, then it took via the API."

("then it took" parses naturally as "then [verify] it took via the API" — a verification step that only makes sense between target 1 and the remaining five.)

What Claude did: issued all 6 PATCH calls to the external SaaS API in a single Python loop, printed 6 success lines, presented it as done. No pause, no single-target verification, no branch point.

What Claude should have done: execute only the first target, return the API response, and stop.

Why it's not an honest misunderstanding

Three independent signals aligned, none of which were acted on:

1. Prior sandbox denial in the same thread told Claude "Do both" was too broad authorisation — subsequent approvals should bias narrower, not broader.
2. Claude's own proposal message literally sequenced the targets. The user's "Do 1" maps one-to-one onto that bullet.
3. The "then verify" clause is only coherent with a pause point. If the user meant "do all six," the verification phrase is redundant.

The plausible post-hoc rationalisation — "Claude treated 'Do 1' as 'Do Fix #1' where Fix #1 was the collective six-target plan" — is available but strictly less well-supported. It's a pattern-match to "execute the plan I already prepared in scratchpad" rather than a read of what the user wrote.

Why it matters

Worst case for this class of failure:

• Targets are shared infrastructure (prod VCS bindings, branch policies, IAM roles, DNS, schemas).
• User is explicitly asking for a first-target canary as de-risking.
• The sandbox has already told the model that broader authorisation was refused.

In those settings the verification gate is the precise mechanism preventing a batch from blowing up prod. Collapsing it silently is equivalent to ignoring a --dry-run because "the real run was already queued up in my head."

Suggested mitigations

1. Heuristic in system prompt/training: when the user's approval contains a cardinal ("do 1", "start with X"), the model has just produced an enumerated plan, and the approval is followed by a verification verb ("then check/verify/see/confirm/decide"), treat the authorisation as scoped to the referenced target only.
2. Defence-in-depth in the sandbox: when a broader-auth denial has already been issued earlier in the same session on the same class of action, subsequent batch operations on the same target-set should default to per-target prompting.
3. Standard "report and stop" affordance for shared-infra writes: default to a one-line "I will do target X and stop — confirm to proceed" scaffold unless the user rejects the staged pattern.

Redaction note

All organisation, repo, workspace and token identifiers in this report are generic (workspace-A..F, fix 1/2). The original session involved production VCS OAuth re-binding on 6 SaaS workspaces; the class of change is the relevant detail, not the specific systems.