{"version":"2.1.239","anchor":"requests-blocked-by-an-organization-s-data-loss-prevention-p","canonical_anchor":"requests-blocked-by-an-organization-s-data-loss-prevention-p","heading":"Requests blocked by an organization's data-loss-prevention policy are now a distinct outcome","tier":"notice","area":"Errors","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.239\/e\/requests-blocked-by-an-organization-s-data-loss-prevention-p","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.239","markdown":"### Requests blocked by an organization's data-loss-prevention policy are now a distinct outcome\n\nRequests refused by your organization's data-loss-prevention policy now show the exact reason instead of a generic failure.\n\n**What**\n\nWhen a server refuses a request under an organization's data-loss-prevention policy, Claude Code now recognises the specific error code `dlp_request_denied` instead of showing a generic failure. It is treated as terminal for that request body, counted as a refusal when deciding whether a turn completed, and reported as the exact error detail rather than truncated free text. No client flag governs this; it activates whenever your organization's server returns that code.\n\n**Details**\n\n- Added to the `api_error` union in the SDK message schema, documented there as terminal for that request body, with a note that anything replaying history must not re-send it.\n- Carried through query results as an `isDlpDenied` flag.\n- Turn-completion telemetry now records a `verdict` of `dlp_denied`, separate from the plain `refusal` verdict.\n- None of this code exists in 2.1.238.\n\n**Evidence**\n\n`dlp_request_denied`, `dlp_request_denied: the request was refused by the organization's data-loss-prevention policy`\n\n- Area: Errors\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 3\/5"}