{"version":"2.1.271","anchor":"strict-kind-permission-request-hook-path-added-for-headless","canonical_anchor":"sdk-strict-permission-prompt-tool-mode-built-but-unreachab","heading":"New 'strict' permission mode for permission-prompt tools (not yet reachable)","tier":"soon","area":"Hooks","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271\/e\/strict-kind-permission-request-hook-path-added-for-headless","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271","markdown":"### New 'strict' permission mode for permission-prompt tools (not yet reachable)\n\nA stricter permission mode that rejects tool calls whose input was changed in disallowed ways is built but not yet wired up\n\n**What**\n\n- The permission-prompt-tool flow was refactored to branch on a `kind`, with the existing behavior renamed \"launcher\" and a new \"strict\" path added. The `kind` is threaded through several internal functions, including `createCanUseTool`.\n\n- Under \"strict\", if a permission answer changed the tool's input in a way that isn't allowed, the tool call is hard-denied instead of running.\n\n- The sandbox's network-ask callback now takes this `kind`: \"launcher\" still applies broad, session-wide permission updates from an allowed network request, while \"strict\" instead applies only limited permission updates.\n\n- The `PermissionRequest` hook handler now validates, for \"strict\" kind, that a hook's `updatedInput` actually matches the original input, denying the call if it doesn't rather than silently accepting the change as before.\n\n**Why**\n\nThis lays the groundwork for a tighter permission mode that can't be bypassed by a hook silently rewriting tool input, though the members indicate this \"strict\" path isn't reachable yet.\n\n- Area: Hooks\n- Tier: Nothing to try yet\n- Useful: 4\/5\n- Signal: 4\/5"}