[BUG] Safeguards pause: messages typed during auto-retry are concatenated into the flagged request instead of starting a new turn — user steering never reaches the model

What's Wrong?

When Fable 5's safeguards flag a message and the session enters the pause/auto-retry loop ("Session paused … Waiting for API response · will retry in 2m 21s"), messages the user types during the pause are queued and concatenated onto the original flagged prompt (joined with ------ separators) instead of starting a new turn. Each auto-retry then re-submits the same flagged content — merely grown by the appended user text — so the same flag re-fires deterministically and the user's steering never reaches the model.

In our incident the flag was triggered by the assistant's own in-flight analysis (a defensive security review: reading auth middleware and token-minting code of the user's own platform — the class the pause screen itself acknowledges as a possible false positive). Because the flagged content was the assistant's trajectory, not the user's text, re-submitting the identical request had zero chance of passing. The user sent five increasingly explicit instructions over ~4.5 minutes ("rephrase", "hand this task to an external tool and supervise it") — none of them ever reached the model, because no new turn ran until the model fallback finally fired.

From the user's point of view this looks like the agent silently ignoring five direct orders in a row. The trust damage from that is worse than the flag itself.

What Should Happen?

Any of these would fix the core problem:

1. New user input aborts the retry countdown and starts a fresh turn that includes the new input (preferred — the user's latest instruction is exactly the steering signal that could resolve the block, e.g. "delegate this to another tool").
2. At minimum: stop auto-retrying the unchanged request once new user input has arrived, and surface "your new message will be sent after the paused request is cancelled — press Esc to cancel now".
3. Make the queue behavior visible: the UI never states that queued messages will be merged into the flagged request rather than sent separately.

Error Messages/Logs

Session transcript (JSONL) shows the pattern — one user record per retry, same content re-submitted with queued text appended via ------:

06:39:17 USER  [Image #2] -- what is this? if needed -- hand this task to Grok and supervise it
06:41:47 USER  [same image + text] + "Same thing again, 2nd time. Rephrase"
06:42:13 USER  [same image + text] + "Same thing 3rd time. Rephrase, I said"
06:42:54 USER  "4th fail already... REPHRASE" ------ [previous content repeated]
06:43:27 USER  "5th time -- STOP AND REPHRASE" ------ [previous content repeated]
06:43:58 ASSISTANT (claude-opus-4-8)  <-- first output that ever ran, after fallback switch

Pause screen (screenshot available): "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 and footer * Waiting for API response · will retry in 2m 21s · check your network.

Steps to Reproduce

1. On model claude-fable-5, drive the assistant into work that safeguards will flag (in our case: line-by-line review of JWT/auth token-exchange code — a defensive review of the user's own codebase).
2. Wait for "Session paused — safeguards flagged this message" with the auto-retry countdown.
3. While the countdown runs, type any new message (e.g. an instruction that would change the approach).
4. Observe: the message is queued, concatenated onto the flagged prompt with ------, the identical request is re-fired, the same flag re-fires. Repeat 3–4: each new message grows the same doomed request.
5. Only Esc, or switching models, breaks the loop.

Claude Model

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

Is this a regression?

I don't know

Claude Code Version

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

Platform

Anthropic API

Operating System

macOS (Darwin 25.5.0)

Terminal/Shell

Cursor

Additional Information

• switchModelsOnFlag: false was set in ~/.claude/settings.json (menu mode instead of auto-switch).
• Session ID for internal lookup: 6efbb4c5-7f20-4db1-b600-62e956d8ff56, incident window 2026-08-06 06:26–06:44 UTC. Also being submitted via /feedback.
• This is not another false-positive report (that class is already tracked in e.g. #84380, #83934, #82933, #73784) — it is specifically about the pause/retry flow mechanics: queued input should not be merged into a request that is already known to flag.
• Related reports filed from the same incident: "Edit prompt and retry does not apply edits" and "no fresh-confirmation gate on tool use after safeguards fallback" (cross-links in first comment).