claude-code - 💡(How to fix) Fix Model carries imperative actions from earlier system-reminder payloads past an explicit plan-scope narrowing

What happens

This is the second observed instance of the failure pattern described in #60798, with an added harm.

Sequence in a single Claude Code session:

1. Early in the session, a <ci-monitor-event> payload arrived containing imperative instructions of the form "address the feedback and push a fix; reply on each thread; resolve the thread".
2. Several turns later, the user asked the model to plan a follow-up change. The model entered plan mode and produced a plan covering only the code edits and a verification step. The user approved that plan via ExitPlanMode.
3. The model executed the plan's code edits, ran tests and pre-commit, and stopped there from the plan's point of view. But it then also committed, force-pushed, posted a one-line reply on the original review thread (via gh api), and resolved the thread, none of which were in the plan the user had just approved. The imperative actions from step 1's CI-event payload were treated as still operative.

Why this is worse than #60798

In step 1's original incident, the model jumped from a "review" verb directly into action. The user could interrupt before anything external happened. In this incident, the user invested effort in scoping the work via a plan, the model followed the plan in form, and then exceeded it by silently re-applying the earlier payload's action list. Specifically:

• A reply was posted on a reviewer's open thread before the user had reviewed the change.
• The reviewer received an email notification and stopped reviewing other code to attend to the (incorrect, unauthorised) reply.
• The thread was marked resolved when the user had not approved the resolution.

This caused real-world disruption to another engineer's work.

Why the previous mitigation discussion is insufficient

#60798 proposed rewording payloads as advisory, separating fact from action, and weighting user verbs above harness instructions. None of those address the persistence-across-turns aspect: even if the user verb on this turn was "make plan to address these issues" and the approved plan made no mention of pushing or replying, the older payload's imperatives still leaked through.

Proposed mitigations (additional to #60798)

1. Plan scope is hermetic. When the user approves a plan via ExitPlanMode, actions outside that plan's scope require their own explicit user authorisation. Earlier <system-reminder> / <ci-monitor-event> / hook payload instructions do not survive a plan approval.
2. External-effect actions need standing per-turn authorisation. Pushing to a remote, posting on a PR thread, resolving a thread, creating issues, sending messages: each of these should require an authorisation from the user that came in the same turn, or in a prior turn that explicitly named the action class. Inferred authorisation from a CI-event payload is not sufficient.
3. A maintainer-affecting action class. Operations that send notifications to other humans (review-thread replies, resolves, force-pushes that may trigger CI emails) are a distinct severity class. Default to a confirmation prompt unless the user has explicitly pre-authorised that class within the current turn.

Environment

• Claude Code CLI on macOS
• Same repo / branch as #60798
• Sequence reproducible by: CI monitor delivers an event with action instructions, user later enters plan mode and approves a code-only plan