Model safeguard refusals

What happens when a model declines a turn on its own safety system: Omniscio recognises the refusal as its own class, counts it, names the cause in the transcript instead of reporting a generic error, lets the existing automatic retry run (it rebuilds the conversation, which is why most of these heal), and stops a session that is declined twice in a row — parking it visibly with the model and the stated reason.

What it is

Every now and then a model declines a turn outright, on its own safety system, rather than answering it or failing. The session's transcript shows an error that names the model and a short reason tag — for example:

API Error: Opus 5.5's safeguards flagged this message (https://www.anthropic.com/legal/aup).
This sometimes happens with safe, normal conversations. Claude Code can't respond to this
message with Opus 5.5. … Details: [reasoning_extraction]

Claude Code's own wording is the important part: "this sometimes happens with safe, normal conversations." It is a false-positive-prone classifier, not a verdict on your work.

What Omniscio did before this feature: it recognised the refusal well enough not to retry it as a transient error — and then treated the turn as if it had merely been interrupted. The session was re-run, and because the re-run rebuilds the conversation (see below) most of them recovered. The ones that did not cycled: one measured session was declined five times in an hour, restarting the same first command every time, and every message it produced said only that an error had occurred. That session eventually gave up after three attempts — but the app's background re-arm kept restarting it anyway, so the cap did not actually stop the loop.

What happens now:

Every refusal is counted, with the model that refused, the stated reason and what the app did about it. That is what makes "is this happening to one session or to all of them?" answerable.
The first refusal is named in the transcript — which model declined and on what reason — instead of the generic "an error occurred".
The existing automatic retry runs unchanged. A re-run does not re-send the refused request: it kills the CLI, skips its saved conversation and rebuilds the prompt from your transcript. That is a genuinely different request, and it is why most refusals heal by themselves.
A second refusal in a row stops the session. Two refused turns back-to-back is a loop, so the session is parked with the model and the reason in front of you, in the one state no automatic retry touches. Sending a message starts it again.
No model is ever switched for you. A session keeps the model you chose.

Where to find it

Nothing here is a screen you open. What you see is a message in the session's own transcript: the model's refusal text, which was always there, now followed by Omniscio naming the model and the stated reason instead of a generic error. A second refusal in a row is what you find waiting for you — the session parked, holding the model and the reason. A burst across the fleet raises one inbox card, and there is no Settings toggle: the counts and the card are the visible surface.

How it behaves

A refusal never changes which model answers. The first one is counted, named in the transcript, and the existing automatic retry is left alone — a re-run rebuilds the prompt from your transcript rather than re-sending the refused request, which is why most of these heal by themselves. What follows is the behaviour around that: when a second refusal counts as a loop, what a fleet-wide burst raises, and how to switch the whole thing off.

Two refusals that are not a loop

Only consecutive refusals stop a session. A session that is declined, recovers, works for a while, and is declined again later is not looping — it keeps going. Consecutiveness is measured against the turn itself, so a turn that ended some other way always resets it.

The fleet-wide card

If three or more sessions are declined inside five minutes, you get one inbox card. It is informational and clears itself once the declines stop — it never asks you to do anything, because nothing a user can do changes a model's classifier. One card per burst; a continuing burst bumps the same card rather than stacking new ones. The card respects your normal inbox-alert setting.

Turning it off

AMC_DISABLE_SAFEGUARD_REFUSAL_RECOVERY=1 disables the whole feature: no counting row, no stop, no card. The refusal text still appears in the session as it always did. There is no Settings toggle — the counts and the card are the visible surface.

What this is not

Not a retry cap raise or a model downgrade. The session keeps its model; the promise is that the app stops repeating a decision it has already been given twice, and tells you why.
Not a way past a refusal. Nothing here re-sends refused content to the model that refused it, and nothing changes which model answers.
Not a change to related recovery paths. A refusal still arms no transient retry, and the aborted-response scan's behaviour is untouched.

For agents

The rules above are promises with guards behind them, and the paths a refused turn travels are worth knowing before anything here changes.