[BUG] Safeguards pause: "Edit prompt and retry" does not apply edits — retries submit the unchanged request

What's Wrong?

On the safeguards pause screen ("Session paused — Fable 5's safeguards flagged this message" with menu 1. Switch to Opus 4.8 / 2. Edit prompt and retry with Fable 5), the "Edit prompt and retry" path did not observably apply any edits. The user attempted to edit and resubmit ~7 times; every retry submitted content identical to the previous failing request (the session transcript shows byte-identical re-submissions, differing only by messages the queue appended — see companion report on queue concatenation). No editor state or "your edited prompt will be…" confirmation was ever observed, and the user's changes had zero effect on what was sent.

Two distinct problems compound here:

1. Mechanical: whatever the edit flow did, the on-the-wire request did not change. Either the edit UI was never successfully entered (nothing indicated it had been), the edit was silently dropped, or it raced with the auto-retry countdown that keeps re-firing the original request concurrently (* Waiting for API response · will retry in 2m 21s remains active under the menu). We cannot distinguish these from the outside — which is itself a UX defect: the user cannot tell whether an edit "took".

1. Conceptual: in this incident the flag was triggered by the assistant's in-flight turn (accumulated auth-code analysis in tool results), not by the user's prompt text. In that case editing the user prompt cannot unblock the session — the re-fired turn contains the same flagged trajectory. The UI still offers "Edit prompt and retry" as the primary same-model remedy, which is misleading: the one thing it suggests fixing is not the thing that was flagged.

What Should Happen?

1. Choosing "Edit prompt and retry" should visibly cancel the pending auto-retry, open the prompt for editing, show what will be submitted, and the next attempt should contain exactly the edited text.
2. The pause screen should say what was flagged — the user's message vs. the assistant's turn/tool results — and only offer remedies that can actually work for that case. When the assistant's trajectory is what flagged, honest options are: switch model, abandon the turn, or send a new instruction; "edit your prompt" is false hope.
3. If an edit was applied, the retry should be visually distinguishable from an automatic re-fire of the unchanged request.

Error Messages/Logs

Session paused
Fable 5's safeguards flagged this message. Our intentionally broad safeguards allow us
to deliver more capabilities faster, but can sometimes flag legitimate coding,
cybersecurity, and biology tasks. Send feedback with /feedback or learn more: …

❯ 1. Switch to Opus 4.8
  2. Edit prompt and retry with Fable 5

* Waiting for API response · will retry in 2m 21s · check your network

Transcript evidence: five re-submissions of the same user record between 06:39:17 and 06:43:27 UTC, none reflecting the user's attempted edits; first successful output only after the model switch (06:43:58, claude-opus-4-8).

Steps to Reproduce

1. On claude-fable-5, get a turn flagged by safeguards through the assistant's own tool-use trajectory (in our case: a defensive review reading JWT/auth token-minting code of the user's own platform).
2. On the pause screen, choose "Edit prompt and retry with Fable 5" and materially change the prompt.
3. Observe the next attempt: the submitted request is unchanged (and the same flag fires). Repeat — same result each time (~7 attempts in our incident).

Claude Model

Other: claude-fable-5 (1M context; effort ultracode/xhigh)

Is this a regression?

I don't know

Claude Code Version

2.1.223 (Claude Code) — latest at time of filing; incident same day, same machine

Platform

Anthropic API

Operating System

macOS (Darwin 25.5.0)

Terminal/Shell

Cursor

Additional Information

• switchModelsOnFlag: false set in ~/.claude/settings.json.
• Session ID for internal lookup: 6efbb4c5-7f20-4db1-b600-62e956d8ff56, 2026-08-06 06:26–06:44 UTC. Also being submitted via /feedback.
• Not a false-positive-flag report (tracked elsewhere, e.g. #84380, #83934) — this is about the edit-and-retry mechanism on the pause screen.
• Companion reports from the same incident: queued-input concatenation during the retry loop; missing fresh-confirmation gate on tool use after fallback (cross-links in first comment).