{"version":"2.1.292","anchor":"structured-io-deny-answers-settle-blanked-prompts","canonical_anchor":"structured-io-deny-answers-settle-blanked-prompts","heading":"Deny answers from SDK hosts now settle blanked permission prompts","tier":"notice","area":"SDK","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.292\/e\/structured-io-deny-answers-settle-blanked-prompts","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.292","markdown":"### Deny answers from SDK hosts now settle blanked permission prompts\n\nA deny response keyed on a tool call's id now settles a pending can_use_tool request whose prompt was blanked, instead of being dropped as unknown\n\n**What**\n\nApps that drive Claude Code through the SDK (the kit that lets other programs control it) answer permission questions by sending back a `control_response`. A permission question is a `can_use_tool` request, which asks whether a tool call, meaning one action Claude wants to take, may go ahead.\n\nSometimes such a request has its prompt blanked: the pending action is published with an empty `request_id` and the original id is kept as a `suppressed_request_id`. Before this release, a deny answer for it was treated as an answer to an unknown request, because the code only looked the response up by its own `request_id`.\n\nNow:\n\n- `blankedPromptDenyTarget` handles a deny response whose `request_id` equals the tool call's `toolUseID`.\n\n- If a published pending action has an empty `request_id` and a matching `suppressed_request_id`, the deny settles the original blanked `can_use_tool` request.\n\n- The request is then cancelled: `enqueueCancelRequest` is called for the response's own id.\n\n**Why**\n\nA deny sent by a host app for a blanked prompt now takes effect instead of being dropped as an unknown response, so the tool call is refused as the host intended.\n\n- Area: SDK\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}