Follow Discord
Sweep 03 Nov 2026 · 22:27Z Build v2.1.318 536 read Stable v2.1.311 Latest v2.1.318 Next v2.1.318 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.318 ·

mcp_tool hooks get their own runner, can block actions, and are restricted from project settings

mcp_tool hooks now wait for servers, report clear failures, can block actions, and are handled more strictly when they come from project settings

Group of 4 You'll notice Improvements
JSON All of v2.1.318
You'll noticeTier: how much it should matter to you
3Useful: my rating, 1 to 5
3Signal: worth watching, 1 to 5
HooksArea: what it touches
ImprovementsKind: in v2.1.318,
ImprovementsSection of the release

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_tool hooks 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 report timed out if the servers do not connect. They report MCP server '...' not connected if 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 projectSettings are skipped when userSettings exist 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 matches mcp_tool hooks from projectSettings. It also matches plugin agent and http hooks whenever pluginId is set; before, agent hooks also needed a further check.
  • Hook-type check: mcp_tool is now included, and the check for agent hooks now looks at the right value, fixing an earlier slip.
  • New options: hook conditions gain an if_pattern option controlled by tengu_woven_ladder, which defaults to an empty list. Nothing has been read about that flag. A hook settings schema gains needsCtrlYFix, 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.

Read from
Names in the bundlemcp_tool
Feature flag
tengu_woven_ladder Not enough to say

Nothing 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

How sure we are
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubtIt is not clear under what condition hooks from project settings are skipped when user settings exist.

See this entry in the whole of v2.1.318 →

Feedback