[FEATURE] Confirmation gate before the first state-changing tool call after a safeguards model fallback (pre-pause directives are stale)

Problem statement

After a safeguards flag forces a model fallback (Fable 5 → Opus 4.8), the session resumes with no checkpoint before the agent's first tool calls. The agent may immediately act on directives issued before the pause — directives that are often stale precisely because the pause happened.

This is a real incident, not a hypothetical. Timeline:

1. Safeguards flagged the assistant's turn mid-task (defensive JWT/auth review of the user's own platform). ~4.5 minutes of blocked retries; during the pause the user's instructions included "if needed — hand this task to Grok [an external LLM CLI] and supervise it".
2. Fallback to Opus 4.8 unblocked output.
3. A few exchanges later, while the user was interrogating what had just happened ("why did retry re-fire unchanged when I explicitly demanded a behavior change?") — i.e. clearly debugging the pause, not driving the task — the agent answered the question and in the same turn executed the external CLI command, treating the pre-pause "hand it to Grok" as live authorization.
4. The user had to interrupt the in-flight tool call and was (rightly) furious: from their perspective the agent ran an external command without current consent, in the middle of an unresolved incident conversation.

The proximate cause was the agent's misjudgment (treating a stale directive as current). But the harness had no mechanism at this boundary to catch it — and this boundary is special: a safeguards pause + forced model swap almost always changes user intent (they are now investigating the disruption, not continuing the task). It is also exactly the moment a different model — which was not the one addressed by the original instructions — starts acting on them.

Proposed behavior

One-shot confirmation gate after a safeguards fallback: before the first state-changing or externally-visible tool call on the fallback model, require explicit user confirmation ("Resume tool use on Opus 4.8? The pending approach was: …"). Read-only calls could be exempt to keep friction minimal.

Alternatives that would also help:

• A harness-injected system reminder into the first post-fallback turn: "The session was paused by safeguards and switched models. Treat pre-pause directives as stale; re-confirm before externally-visible actions." (Weaker, but zero-friction.)
• A setting (confirmToolsAfterFallback: true) for users who want the hard gate.

Precedents in the product for exactly this shape of control: plan mode's exit gate, and per-tool permission prompts. This asks for the same pattern at one rare, trust-sensitive transition.

Environment (incident)

• Claude Code 2.1.223 (latest at filing; incident same day), Anthropic API, macOS (Darwin 25.5.0), Cursor terminal.
• Model at incident: claude-fable-5 (1M context, effort ultracode/xhigh) → fallback claude-opus-4-8.
• switchModelsOnFlag: false in ~/.claude/settings.json.
• Session ID for internal lookup: 6efbb4c5-7f20-4db1-b600-62e956d8ff56, 2026-08-06 06:26–06:56 UTC. Also being submitted via /feedback.

Additional context

• Not a false-positive-flag report (tracked in e.g. #84380, #83934, #73784). This is about what the harness allows immediately after the fallback.
• Companion reports from the same incident: queued user input concatenated into the flagged request during the retry loop; "Edit prompt and retry" not applying edits (cross-links in first comment).