{"version":"2.1.300","anchor":"hook-updatedinput-rewrites-are-now-validated-against-the-too","canonical_anchor":"hook-updatedinput-rewrites-are-now-validated-against-the-too","heading":"Hooks that check tool calls are handled more strictly","tier":"notice","area":"Hooks","scope":"both","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.300\/e\/hook-updatedinput-rewrites-are-now-validated-against-the-too","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.300","markdown":"### Hooks that check tool calls are handled more strictly\n\nPreToolUse and PermissionRequest hooks now have input rewrites validated, fail toward refusing or asking, and can't switch mode in some cloud sessions\n\n**Unclear.** Whether a malformed hook change is refused in an interactive session when the remote setting is off, or only recorded, is not settled.\n\n**What**\n\nHooks 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:\n\n- `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.\n\n- 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.\n\n- 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.\n\n- 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.\n\n- 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.\n\n- `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.\n\n**Why**\n\nIf 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.\n\n- Area: Hooks\n- Names: `updatedInput`, `PreToolUse`, `PermissionRequest`\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 3\/5\n- Scope: both\n- Heads-up: yes"}