Hooks get new rules for allowing, asking and refusing tool permissions

What

A hook is a command you or a plugin set up to run automatically at certain moments. PreToolUse hooks run before a tool is used and can block it; PermissionRequest hooks run when a tool use needs a permission decision. This release changes how their answers combine:

• PreToolUse and PermissionRequest hook decisions (allow, ask or deny) are now routed through a tool.check path in a permission engine, and handlers can answer for the engine.
• A plugin's tool.check deny no longer always blocks. If the tool is not a protected one, the original check is recomputed, and if that would have asked you, you get an ask with a refusal attached instead. Before, the plugin's result was used directly.
• An ask raised by a hook can now carry hooksMayAllow and refusal, and a PermissionRequest hook may now allow such an ask, under strict checks. Before, that hook could only deny. Headless and no-prompt runs, where nobody can answer, consult hooks before denying.
• The prompt for a blocked browser action now sets hooksMayAllow to false, next to personOnly and defaultToNo, so hooks cannot approve it.
• A new hookAskFloor setting keeps a hook's ask in place, and stops hook-approved automatic allowing, when a sandboxOverride applies.
• The auto mode decision record gains skippedOnAllowRule.
• The error log text now reads 'PermissionRequest hook failed before a hook's ask for', replacing 'PermissionRequest hook failed before an ask of a person for'.

Why

Hook and plugin authors should check their setups: a plugin deny may now show you a prompt instead of an outright block, and a PermissionRequest hook can now approve asks that other hooks raised. Some prompts, such as blocked browser actions, remain for a person only.