Unclear The finding shows the strict branch exists in code but does not show anything that selects or reaches it, so it is not yet active for any consumer.
What
- The permission-prompt-tool flow was refactored to branch on a
kind, with the existing behavior renamed "launcher" and a new "strict" path added. Thekindis threaded through several internal functions, includingcreateCanUseTool. - 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.
- 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. - The
PermissionRequesthook handler now validates, for "strict" kind, that a hook'supdatedInputactually matches the original input, denying the call if it doesn't rather than silently accepting the change as before.
Why
This 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.
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubt
The finding shows the strict branch exists in code but does not show anything that selects or reaches it, so it is not yet active for any…