Unclear It is not clear under what condition hooks from project settings are skipped when user settings exist.
What
A hook is a command you set up to run automatically at certain moments while Claude Code works. An mcp_tool hook calls a tool on an MCP server, an outside service that gives Claude tools. Claude Code could already read this hook type when a remote list allowed it. What changed now:
- Own runner:
mcp_toolhooks now run through their own path instead of the general one. They wait for plugin MCP servers to connect, up to the hook's time limit, and reporttimed outif the servers do not connect. They reportMCP server '...' not connectedif the server is missing, and "The organization's MCP server lists could not be applied to" a server when that check fails. - Blocking: a response that is not empty is now recorded, and a new check can mark the result as blocked, using the response as the output. A blocking failure has the new code
hook_mcp_tool_failed. Before, these hooks only failed when aborted, on an error, or when the call was not ok, and they never blocked. - Project settings: hooks from
projectSettingsare skipped whenuserSettingsexist and a new check is true. They may also go through a different runner when an input stream is available. The check for restricted hook sources now also matchesmcp_toolhooks fromprojectSettings. It also matches pluginagentandhttphooks wheneverpluginIdis set; before,agenthooks also needed a further check. - Hook-type check:
mcp_toolis now included, and the check foragenthooks now looks at the right value, fixing an earlier slip. - New options: hook conditions gain an
if_patternoption controlled bytengu_woven_ladder, which defaults to an empty list. Nothing has been read about that flag. A hook settings schema gainsneedsCtrlYFix, which can only be true. - Abort check: the hook list is now passed to a new function before the abort check.
Why
If you write mcp_tool hooks, they can now stop an action, and their failures say what went wrong. Hooks that come from a project's settings are treated more strictly, so a project cannot always run them the way your own settings can.
tengu_woven_ladder Not enough to sayNothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.
This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.318: not a boolean we can read
These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.
Read once, for one account on one subscription tier, against v2.1.318. It isn't a statement about your account. What a flag value here can and cannot tell you
It is not clear under what condition hooks from project settings are skipped when user settings exist.