Hooks that check tool calls are handled more strictly

What

Hooks are your own commands that Claude Code runs automatically at set points. A PreToolUse hook runs before a tool call (an action Claude wants to take, such as running a command or editing a file) and can block it. A PermissionRequest hook runs when a tool call needs a permission decision. Several parts of how these hooks are handled changed, mostly so that a hook problem leads to refusing or asking rather than running the call anyway. Claude Code already refused input changes from plugin hooks running on another machine; these changes go further:

• updatedInput checks: when one of these hooks sends back updatedInput (a changed version of the tool call's input), the change is now checked against the input the tool expects. The call is denied if that check fails, if the tool's own validation refuses the input, or if the check itself crashes. Unknown keys are dropped and any key starting with __artifact is refused. Dropping and denying are enforced only in some cases (the finding points to non-interactive sessions, or a feature flag allowing it); otherwise the original input is kept and the check is only recorded.
• Refusal wording: the reason given when an updatedInput change is refused now has two versions, chosen by an ofSettings flag, instead of one fixed message.
• Unfinished hooks: when a PreToolUse hook does not finish (for example it hangs or is stopped), the call is still refused, the block is now marked with hookDidNotFinish, and the event is recorded. If the call was already denied for another reason, that original deny is now kept instead of being replaced.
• Unread organization settings: when your organization's managed settings (settings an administrator applies for everyone) could not be read, your own hooks and mods do not run, and a tool call a PreToolUse hook should have checked asks you for permission instead of being allowed. The message says the hook isn't running because your organization's settings couldn't be read.
• Managed hooks that fail to load: settings validation now explains that a PreToolUse or PermissionRequest hook in the managed settings document that cannot be loaded does not run, nor does any other hook in that document, while the managed settings document itself is not skipped, unlike a user or project settings file.
• setMode removal: when a PermissionRequest hook answers allow, any setMode update in that answer (a request to switch the session's permission mode) is now removed in a Cowork cloud session or where an MCP tool is declared as code-running.

Why

If you write hooks, a hook that returns malformed updatedInput or never finishes may now get tool calls denied, and missing organization settings can turn silent approvals into permission prompts. In Cowork cloud sessions and with code-running MCP tools, a hook can no longer use its allow answer to change the session's permission mode.