{"version":"2.1.268","anchor":"new-tool-kind-field-on-permission-requests-wired-for-brow","canonical_anchor":"new-browser-tool-kind-added-to-the-permission-request-sche","heading":"Permission requests can now carry a browser tool_kind for SDK hosts","tier":"use","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268\/e\/new-tool-kind-field-on-permission-requests-wired-for-brow","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268","markdown":"### Permission requests can now carry a browser tool_kind for SDK hosts\n\nTool-use permission requests can now be tagged tool_kind: \"browser\" so SDK hosts can route browser tools to a specialized UI\n\n**What** The tool-use permission request payload (the `can_use_tool` control-protocol message) gained an optional `tool_kind` field, currently only ever set to `\"browser\"`. This lets SDK hosts \u2014 such as Claude in Chrome, Cowork, Claude Desktop, or Remote Devices \u2014 recognize browser-related tool calls and show a specialized permission prompt for them, instead of having to guess by matching the tool's name. The field is now actually populated (`tool_kind: \"browser\"`) on real requests, not just declared in the schema.\n\n**Why** Browser tools often need a different kind of approval UI than regular tools. Tagging them explicitly lets host applications build that UI reliably instead of relying on fragile name-matching.\n\n- Area: Elsewhere\n- Names: `tool_kind`\n- Tier: Use it now\n- Useful: 3\/5\n- Signal: 2\/5"}