Claude Code hook matchers written as a bare MCP server prefix silently match no tool

Claude Code decides how to read a hook matcher from the characters in it ^[10]. A string made only of letters, digits, underscores, hyphens, spaces, commas and pipes is an exact name, or a list of exact names ^[10]. Any other character makes it a JavaScript regular expression, unanchored ^[10]. For tool events the value tested is tool_name, and MCP tools are named mcp__<server>__<tool> ^[11][12]. So mcp__lab is compared whole, and no tool has that name ^[10][12]. The hooks reference says so directly: the bare prefix "is compared as an exact string and matches no tool" ^[6].

Appending .* adds a character outside the exact set ^[6][10]. The pattern then runs through RegExp.prototype.test, and that test succeeds on a match anywhere in the value ^[11]. Plugin-bundled servers get a scoped segment instead: mcp__plugin_<plugin-name>_<server-name>__<tool> ^[13]. In that name mcp__ is followed by plugin_, so the substring mcp__lab__ never occurs and the unanchored test finds nothing ^[20]. The docs warn that a matcher written against the bare server key "never fires for these tools" ^[13]. By the same naming rule, we'd expect mcp__plugin_<plugin-name>_lab__.* to cover the bundled copy ^[21].

The permissions page reads the same string another way: "mcp__puppeteer matches any tool provided by the puppeteer server" ^[14]. The --allowedTools result follows from that rule ^[3]. The hooks page describes each handler's if field as "Permission rule syntax to filter when this hook runs" ^[15]. In our view the if result is the one to take upstream. The matcher and plugin failures follow rules the docs state, and this one contradicts them ^[4][15].

Hooks on an MCP server usually exist to log every call or to check a call before it runs, according to the writeup ^[18]. A matcher that matches nothing gives such a hook an excellent error record. The settings file loads and the session runs, but the hook never starts ^[7].

Matchers have gone quiet before. The 2.1.191 changelog entry fixed "hooks with comma-separated matchers" that were "silently never firing" ^[16]. In 2.1.195, hyphenated matchers such as mcp__brave-search stopped "accidentally substring-matching" and now exact-match, with mcp__brave-search__.* given as the way to match a whole server ^[17].

The counts come from 14 headless runs on 2026-10-05, using Claude Code 2.1.289 and claude-opus-5-5 ^[1][9]. The test server is a dependency-free Node script that reads newline-delimited JSON-RPC on stdin ^[19]. The writeup registered 22 hook groups side by side against its three tools and counted which fired for which tool ^[8]. Matching is string comparison against tool_name, so we'd expect the fire-or-not results to hold under other models ^[11]. They hold on other releases only while the matcher grammar stays the same, and the changelog records two changes to it, in 2.1.191 and 2.1.195 ^[16][17].