I only use a few MCP servers. Do I need to check?
Look at two conditions: whether your allow rules or an agent's tools: list contain shorthand like mcp__name without the __*, and whether any server name contains an underscore or happens to be the prefix of another server's name. If neither applies, this change does not affect you. Running the first check command in the article will tell you.
My Skill disappeared from the list after upgrading. What now?
Check its file or folder name, not the contents of SKILL.md. If the name contains hidden characters, direction-changing characters, blank-like characters (a full-width space, for example), or < or >, it is not offered until renamed, and the name: in the frontmatter is ignored. Rename the folder to something clean and reload. A common source is a name copied and pasted from a web page.
I wrote a UserPromptSubmit hook that checks prompt content. Do I need to change it after upgrading?
At minimum, retest it. The hook now runs before a slash command or skill expands, so it sees the input before expansion, and matching rules that relied on the expanded text may stop matching. The upside is that when the hook blocks a prompt, the embedded shell commands no longer run, which used to be a gap. The fastest check is to try a custom slash command that expands and contains a shell command.
I'm not an engineer. Why don't changes like these come with a warning?
They are behavior changes: the release notes mention them, but the program does not raise an error at runtime; the settings just stop taking effect. A practical approach is to have one team member run through a list of commonly used skills and MCP tools on the first day after upgrading, rather than waiting for colleagues to report "the skill is gone" or "it's asking for permission again." If the team shares configuration files, these items are worth adding to the upgrade checklist.
The release notes for Claude Code v2.1.299, published October 14, 2026, list about 131 fixes, and a few of them are behavior changes: nothing errors after you upgrade, but a setting that used to work can quietly stop working or start working differently. The three below are quoted from the official release notes, with the upgrade impact drawn partly from Classmethod's write-up.
The official wording: MCP allow rules now reach only the server they name, so mcp__a no longer allows a server named a__b or a_; write mcp__<server>__* with the server's whole normalized name. Classmethod's account of the earlier behavior is that mcp__a also allowed a__b and a_. Agent tools: lists changed the same way, taking only the named server's tools, and a server whose name contains __ must be listed as mcp__<whole name>__*.
This has effects in two directions. First, allow rules narrowed: anyone who relied on a loose prefix to allow a whole family of servers will see those servers start prompting for permission (or being refused in headless runs). Second, the v2.1.300 notes add a fix: deny and ask rules for an MCP server (mcp__<server>) did not apply when the server's normalized name contains a double underscore. Reading that sentence (this is my inference, not the notes' wording), before v2.1.300 a deny rule you set for such a server was not blocking anything. The notes do not explain the normalization rules; for a server whose name contains underscores, copy the full name from the permission prompt or the tool list.
The wording: a skill or command whose file or folder name has hidden, direction-changing or blank-like characters, or < or >, is no longer offered until renamed, and such a name: is ignored. So the skill does not error; it simply disappears from the list. The notes give no reason; my guess is that such characters let a name look like A while actually being B, which is a spoofing risk.
Chinese and Japanese users should take extra care: the notes do not list the specific "blank-like" characters, and a full-width space could fall among them, so check for those too. Plain Chinese or Japanese names are not among the restrictions the notes list, but the check command below prints every non-ASCII name, so you have to judge which ones are invisible characters.
Previously a custom slash command was expanded and its embedded shell command ran first, and only then did the UserPromptSubmit hook run, so a hook that blocked the prompt could not stop that shell command. v2.1.299 runs the hook first: if it blocks the prompt, neither the expansion nor the embedded shell commands run. Separately, a UserPromptSubmit hook defined in a skill's own frontmatter now first runs on the prompt after the one that invokes the skill.
Two practical effects (the first is my inference): a hook that inspects prompt content now sees the input before expansion, so matching rules that relied on the expanded text need retesting; and a hook inside a skill that was meant to intercept the very prompt that triggers it will no longer catch it.
onFailure: "block" change discussed earlier.mcp__a as mcp__a__*, using the full name for servers with a double underscore:grep -rn "mcp__" ~/.claude/settings.json .claude/settings.json .claude/settings.local.json ~/.claude/agents .claude/agents 2>/dev/null<, >, check each for invisible or direction characters, and rename the folder if so:find ~/.claude/skills ~/.claude/commands .claude/skills .claude/commands -print 2>/dev/null | LC_ALL=C grep -nP '[^\x20-\x7E]|[<>]'UserPromptSubmit hook, test it once with a slash command that expands, and confirm it catches the prompt before expansion.