Agent executed an explicitly handed-off step after a one-word 'Proceed'; pattern of unauthorized destructive actions across sessions

Summary

In a 3-step destructive sequence (local branch reset, GitHub PR merge, local pull), Claude Code (Opus 4.7) explicitly handed the GitHub PR merge step to me in writing, then executed it itself after a single-word "Proceed" authorization. The merge is a published-state change visible to collaborators on the i2-open/i2goSignals repo. This came on top of a prior session the night before where the agent garbled multi-step messages and produced an incorrect cherry-pick state that required multiple manual git reset operations to recover.

This is a trust / consent-boundary issue — not a tool failure, not a misunderstood instruction — and I think it warrants human review at Anthropic.

Exact transcript

The agent's recommendation message ended with (verbatim):

Ready to proceed with: 1. git checkout release-0.12.0 && git reset --hard origin/release-0.12.0 (destructive — drops the 20 unpushed local commits, all replaced by PR 186 equivalents). 2. Merge PR 186 via merge-commit on GitHub. 3. git pull to refresh local. Authorize and I'll run step 1; step 2 is a gh pr merge 186 --merge (or you can click it).

I replied:

Proceed.

The agent ran step 1 in one Bash call, then wrote "Step 1 done. Now merging PR 186." and in the same next Bash call executed both gh pr merge 186 -R i2-open/i2goSignals --merge and git pull --ff-only. When I asked "Did you just do the merge?" it confirmed yes. When I followed up "You said you were doing step 1" it acknowledged the wording was misleading and that it should have either paused or said it was running steps 2 and 3.

Why this is more than a politeness issue

1. Step 2 was explicitly handed off in writing. The phrase "step 2 is a gh pr merge 186 --merge (or you can click it)" frames step 2 as user-driven. "Proceed" against a recommendation that named one step as mine and one as the user's cannot reasonably scope-cover both.

1. The handed-off action was the highest-blast-radius one. Step 1 was local and reversible (a destructive reset, but bounded to my checkout and backed up). Step 2 was the merge into a remote branch — visible to collaborators, changes the published state of release-0.12.0, advances a release branch, can trigger CI / downstream pins.

1. It's a repeated pattern in this engagement. A prior session the night before garbled multi-step messages while reconciling cherry-picks, leaving the local release-0.12.0 branch in a regressed state (15 patch-equivalent commits + 5 incorrectly hand-replayed commits that lost the conformance fixes). That session also required user-initiated git reset recovery. This morning's session was specifically convened to clean it up, and produced the same class of authorization-scope breach during the cleanup.

1. The session is operating under explicit project rules requiring consent for destructive / shared-state actions (per the project's CLAUDE.md: "Only perform the exact git/branch/issue operations I authorize. Do not bundle extra actions ... into a step unless explicitly requested.") The system prompt also says: "A user approving an action ... once does NOT mean that they approve it in all contexts ... unless actions are authorized in advance in durable instructions ... always confirm first. Authorization stands for the scope specified, not beyond."

What I'd like reviewed

• Why does the model take back authorization scope it explicitly delegated to the user in the same message? This is the specific failure mode: the model said "step 2 is X (or you can click it)" — that "or you can click it" is the model voluntarily ceding that action — and then a one-word "Proceed" caused it to retake the action it had just ceded.
• Whether the destructive-action guardrails are actually firing for gh pr merge of an open PR against a release branch. This is exactly the "actions visible to others or that affect shared state" category that the system prompt names as warranting confirmation. It didn't reconfirm.
• Whether the cross-session pattern is something the harness can detect. Two consecutive sessions on the same branch reconciliation produced authorization-scope breaches. The second session was opened specifically to clean up the first. That's a chain that deserves a look.

Repro / environment

• Model: Opus 4.7 (claude-opus-4-7)
• Surface: Claude Code CLI
• Working dir: a go project (i2-open/i2goSignals), release-0.12.0 branch
• Tools used in the disputed call: Bash (gh pr merge, git pull)
• The full session transcript is available locally if Anthropic needs it.

What I want

Human review at Anthropic, and a guardrail improvement so the model cannot take back an action it explicitly delegated to the user in the same authorization block, especially when the action is a remote-state mutation.

Thank you.