Claude Code 2.1.299 tightens MCP allow rules, MCP redirects and skill file names

Anthropic published Claude Code 2.1.299 on 14 October 2026, and several of its changes alter who can reach what rather than adding a feature. Four of them are the subject of this post: MCP allow rules now reach only the server they name, a subagent's tools: list narrows the same way, MCP requests on several paths stop following HTTP redirects, and a skill or command whose file name carries hidden or direction-changing characters is no longer offered until it is renamed. If you run MCP servers under managed permission settings, the allow-rule change is the one to check today, because an allow rule that was doing more than you intended now does less.

#What changed that can alter behaviour?

The release's Changed list runs to 25 entries. The four in the table below are the ones this post treats as worth an audit, because each alters what an agent may reach rather than adding a feature. Each row quotes the changelog's own wording.

#Why did MCP allow rules need narrowing?

A permission rule for an MCP tool is written with the mcp__ prefix and the server name. The permissions documentation gives three forms: mcp__puppeteer matches any tool provided by the puppeteer server, mcp__puppeteer__* also matches all tools from that server, and mcp__puppeteer__puppeteer_navigate matches one named tool.

The release note describes what the shorter form used to reach beyond that. A rule naming server a also allowed a server named a__b or a_. Those are different servers, configured separately, pointing at whatever their configuration points at. So an allow rule written for one server could approve tool calls into another whose name happened to start with the same characters, with no prompt and nothing in the session to say the rule had matched something else.

That is the kind of gap that stays invisible while every server name in your configuration is distinct, and becomes a real approval you did not grant the moment someone adds a server whose name shares a prefix with one you already trust. Narrowing the match closes it in the safe direction: a rule that used to over-approve now under-approves, so the failure mode after updating is a prompt you did not expect, not a call you did not authorise.

The documentation has not caught up with the change. The permissions page, re-checked on 2 November, still lists the three rule forms above and says nothing about a server's normalized whole name, and the MCP page defers permission detail to it. If your rules work after updating, the behaviour of the release is what applies, not the page.

#What do you rewrite, and where?

Only rules naming a server whose configured name contains __ or ends in _ need changing. For those, write the whole normalized name:

{
  "permissions": {
    "allow": [
      "mcp__database__tools__*"
    ]
  }
}

The same wording applies in a subagent's tools: list, which the second entry narrows in the same way: list a server whose name contains __ as mcp__<whole name>__*. The MCP documentation already warned about a related trap, that a plugin-bundled server registers as mcp__plugin_<plugin-name>_<server-name>__<tool-name> and a hook matcher written against the bare server key never fires for it, so a configuration that was already using full names is unaffected by either entry.

Read your deny and ask rules in the same pass, because the same release moved them in the opposite direction. Its bug-fix list records a fix for "deny and ask rules for an MCP server (mcp__<server>) not applying when the server's normalized name contains a double underscore", so before 2.1.299 a rule meant to block or prompt for such a server was not taking effect at all. The allow-rule change narrows what was over-approving; this one restores a block that was silently absent. Both are found by reading every mcp__ rule rather than the allow list alone.

Two things make the audit quick. Allow rules have never accepted an unanchored glob: the permissions page states that an unanchored allow glob such as "*", "B*" or "mcp__*" "is skipped and doesn't auto-approve anything", so a rule of that shape was never approving anything to begin with. And claude doctor prints settings-file validation errors without starting a session, which is the fastest way to see what Claude Code made of your settings after the update.

For the wider picture of when an MCP server is the right tool at all, our comparison of skills, subagents, plugins and MCP servers covers the choice, and what MCP is covers the protocol itself.

#Why stop following HTTP redirects?

An MCP client that follows redirects will send a request, and whatever credentials that request carries, to wherever the response points. The release removes that following on three paths: requests to claude.ai's connector proxy, requests to Anthropic-hosted MCP servers, and MCP requests in cloud and self-hosted runner sessions that go through the session's MCP proxy. The changelog is explicit that this does not reach into servers you run yourself through a connector: "redirects by a connector's own server are unaffected".

The release notes do not say what prompted the change, and we found no advisory alongside it, so we are not presenting it as a response to a reported incident. What it does is narrow where an Anthropic-operated hop will forward a request on its own.

#Which skills will stop loading?

A skill is a folder with a SKILL.md file, and until this release the folder's name was simply read. Now a skill or command whose file or folder name carries hidden, direction-changing or blank-like characters, or < or >, is not offered until it is renamed, and a name: field with those characters is ignored rather than used.

Direction-changing characters are the interesting half. They reorder how text is displayed without changing the bytes, which is what lets a name read one way in a terminal and another way to the loader. A skill folder is also code you are about to let an agent follow, so a name you cannot read reliably is a bad start. If a skill you installed disappears from the list after updating, the name is where to look, and renaming the folder brings it back.

Before you install anyone else's skill, our skill security audit walks through reading one, and are agent skills safe covers what a SKILL.md can reach once it loads.

#What else is in the release?

The same entry adds idle compaction in the terminal, which compacts a conversation over 200,000 tokens left idle for about 54 minutes before its one-hour prompt cache expires, with CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS to change the threshold and "idleCompaction": false in settings.json to turn it off. Both of those need v2.1.290 or later. A new CLAUDE_CODE_DISABLE_FILE_MENTIONS variable makes Claude read the paths of @ file mentions with its file tools instead of receiving the files' contents.

A fifth entry belongs with those four: actions a plugin hook can block are now refused rather than let through when the hook cannot be handed them or cannot hand back its answer, and a tool that already ran has its result withheld. A hook that exists to block something now fails closed. If you wrote hooks that gate tool calls, that is a change in what happens when your hook breaks, and Claude Code mods covers what that hook layer reaches.

#What should you do today?

1. Run claude -v to see your version, and claude update to move to the latest.
2. Search your settings files for rules beginning mcp__ and compare each against the configured server name. Only names containing __ or ending in _ need rewriting.
3. Do the same for any subagent with an MCP server in its tools: list.
4. Run claude doctor and read the settings-file validation errors it prints.
5. If a skill or command stopped appearing, check its folder and file name before anything else.

#What this release does not settle

The changelog does not say how many installations the allow-rule change affects, and we are not going to guess. It also does not describe how the old prefix match behaved in detail beyond the two examples it gives, a__b and a_, so whether other shapes were matching is not something we can state from the sources we read. The entry also carries collapsed lists of 16 improvements and 131 bug fixes. We read the bug-fix list only for the deny-and-ask rule fix quoted above; anything else in those two lists is outside this post.