Under the hoodTier: how much it should matter to you
1Useful: my rating, 1 to 5
1Signal: worth watching, 1 to 5
Error HandlingArea: what it touches
Internal ChangesKind: in v2.1.280,
Internal ChangesSection of the release
What
A new failure reason, safety_monitor_blocked, is now recognized in two places:
The tool/DLP failure classifier, which previously only special-cased dlp_request_denied, now also treats safety_monitor_blocked as a hard failure reported as an API error.
The predicate that decides whether an API response counts as a refusal now also treats apiError === 'safety_monitor_blocked' as a refusal, alongside the existing stop_reason: 'refusal' and dlp_request_denied checks.
Why
This makes sure that when Claude Code's safety monitor blocks a response, that outcome is consistently surfaced as an error and treated as a refusal, matching how other blocked/denied conditions already behave.
