{"version":"2.1.280","anchor":"new-safety-monitor-blocked-failure-reason-maps-to-an-api-e","canonical_anchor":"new-safety-monitor-blocked-failure-reason-maps-to-an-api-e","heading":"New 'safety_monitor_blocked' reason recognized as a hard failure and a refusal","tier":"internal","area":"Error Handling","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/new-safety-monitor-blocked-failure-reason-maps-to-an-api-e","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### New 'safety_monitor_blocked' reason recognized as a hard failure and a refusal\n\nTool calls blocked by the safety monitor now count as an API error and are treated as a refusal, alongside dlp_request_denied\n\n**What**\n\nA new failure reason, `safety_monitor_blocked`, is now recognized in two places:\n\n- 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.\n\n- 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.\n\n**Why**\n\nThis 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.\n\n- Area: Error Handling\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}