My MCP Server names have no double underscore. Do I need to change my rules?
Probably not. This change mainly affects servers whose names contain __ or end in _, and the usual forms mcp__server and mcp__server__* remain valid per the documentation.
Still, run claude doctor after upgrading to confirm no rules are being skipped for containing parentheses or unanchored wildcards.
My automation suddenly fails after upgrading. Could this be the cause?
Possibly, especially if you use dontAsk mode and a server's name contains __. Once the old looser matching is gone, the tools are no longer allowed, and dontAsk never prompts, so the calls are denied outright.
Use claude doctor to look for skipped rules, then rewrite the relevant allow rules into the mcp__whole-name__* form.
Are deny rules affected too?
The changelog entry is about allow rules, and I found no equivalent statement about deny rules, so I cannot say. The permissions documentation separately notes that deny and ask rules can use leading wildcards such as mcp__*.
For rules that Block things, test each once after upgrading to confirm the servers you meant to block really are blocked.
How do I find MCP servers with double underscores in my configuration?
The most direct way is to list your configured server names in /mcp and check each for __ or a trailing _. For servers provided by plugins, look at the full Plugin-scoped form.
Once found, rewrite the matching allow rules as mcp__whole-name__* and put them in shared settings so the whole team uses the same form.
Claude Code v2.1.299 (October 14, 2026) includes a security-relevant entry under Changed: MCP allow rules now reach only the server they name, so mcp__a no longer allows a server named a__b or a_; the same release also makes an agent's tools: list take only the named MCP Server's tools. If a server name contains __, you need to rewrite the rule as mcp__<whole name>__*.
An MCP tool's full name in Claude Code is mcp__<server>__<tool>, and __ is also the separator. The official permissions documentation now says explicitly that a server name containing __ or ending in _ must be written in the wildcard form mcp__<server>__* with the whole name. For a server named reports__v2, write mcp__reports__v2__*; the bare mcp__reports__v2 and the shorter mcp__reports do not match its tools, because Claude Code reads both as rules for a server named reports. In other words, old allow rules may have reached further than their authors intended (this is my inference from the changelog's phrase "no longer allows"; the official notes do not describe the old behavior in detail).
The documentation adds that characters such as . or spaces in a server name become _, so a server configured as my.server is written mcp__my_server__*; servers provided by a Plugin use the plugin-scoped form, such as mcp__plugin_my-plugin_database-tools__*. Wildcards in allow rules are also restricted: they are allowed only after the literal mcp__<server>__ prefix, and the server segment must be glob-free; unanchored allow rules such as * or mcp__* are skipped with a warning and approve nothing. An mcp__ rule containing parentheses is skipped when settings load, and to restrict by parameter you must use a deny rule with --disallowedTools.
If one of your servers has __ in its name and an allow rule only worked through the old looser matching, its tools will start prompting again after the upgrade; in dontAsk mode, which never prompts, those calls are denied outright, so an automation may suddenly fail. That is the fail-closed direction, safer than silently allowing, but disruptive. Before upgrading, list all your MCP server names, find any containing __ or ending in _, and use claude doctor to check for skipped rules.
If your team pre-approves MCP servers through managed settings or a shared settings.json, this change is a cheap audit opportunity: spend ten minutes listing every mcp__ allow rule, confirm each points at the server you think it does, and rewrite any with double underscores into the full wildcard form. Permission rules written broader than their intent usually get noticed only after an incident; this upgrade at least makes that kind of ambiguity visible.