None of my MCP servers are defined in managed-mcp.json. Should I worry?
Read literally, the changelog line targets stdio servers in managed-mcp.json whose ${VAR} appears only in env. Servers from other sources are not covered by that line.
I did not verify every combination, though, so if you control MCP through managed settings, still compare the actually loaded list with /mcp after upgrading.
How do I keep a particular server blocked?
Per the summary, list it explicitly in deniedMcpServers. The example uses serverCommand pointing to that server's executable.
Afterward, open a clean session and confirm with /mcp that it does not appear, instead of only reading the config file.
Is this a bug fix or a deliberate policy change?
The changelog lists it under Changed and words it as stopping the filtering, which looks like a deliberate behavior adjustment. I found no official explanation of why.
Since the motive is unclear, treat it as a change whose impact you must assess yourself rather than waiting for an explanation.
How can I check the impact before upgrading?
The most direct way is to open managed-mcp.json, list all stdio servers, mark those whose ${VAR} appears only in env, then compare with your allowlist to see which would previously have been excluded.
That list is the set of servers most likely to appear extra after the upgrade, so decide one by one whether to add each to deniedMcpServers.
The Changed section of Claude Code v2.1.305 (October 20, 2026) says allowedMcpServers no longer filters managed-mcp.json stdio servers that use ${VAR} only in env. It is easy to read this as a small tweak, but for administrators who control MCP through managed settings, the direction is loosening, not tightening.
According to a third-party summary, up to v2.1.304 a stdio server defined in managed-mcp.json whose only ${VAR} reference was in the env field was excluded if it was not on the allowedMcpServers list. From v2.1.305 such a server is no longer filtered by the allowlist and loads on upgrade. To keep it blocked, you must list it explicitly in deniedMcpServers. For example, suppose managed-mcp.json defines a server company-internal that uses ${COMPANY_API_TOKEN} only in env, and the allowlist contains a single approved npx package: before the upgrade it would not load, after it would, unless you add a deniedMcpServers entry pointing to its executable.
That same third-party summary also notes that the official managed-mcp documentation seems to describe allowlist filtering over more places than the changelog line does, including ${VAR} references in command, args, env, URL and headers. I did not check that part of the official documentation myself, so this is secondhand. The takeaway is not to trust either side alone: read both before upgrading, and verify in your real environment.
An allowlist exists so that anything not named does not load. This change moves one class of servers from blocked by default to allowed by default unless you Block it separately. If that server carries an internal API credential, like the Token in the example, and gets loaded without your knowing, the impact is not only functionality but what data it can reach. And the change is silent: no error appears, a server just shows up in the session.
If your team restricts MCP servers through managed settings, spend ten minutes before rolling out v2.1.305 or later: find the stdio servers in managed-mcp.json whose ${VAR} appears only in env, decide whether they should load, and add deniedMcpServers entries for any that should not. After upgrading, open a clean session, list the loaded servers with /mcp, and compare against what you expect. The cost of an extra server that should not be there usually arrives not on upgrade day but on the day it gets used.