Claude Code 2.1.305 and 2.1.306: the MCP allowlist change to check before you upgrade

If you administer Claude Code and your organization deploys a managed-mcp.json, read the MCP line in 2.1.305 before anyone upgrades: an allowlist that was keeping one of your own managed servers from loading may stop doing so, with no prompt. That is the one change in these two releases that can widen what runs on a developer's machine rather than narrow it. The rest of 2.1.305 is a large maintenance release, 6 improvements and 22 bug fixes by the changelog's own headings, and the headline fix in it repairs a 2.1.304 regression that made every request fail on Vertex, Bedrock and gateway setups that reject tool search.

Neither version is dated in Anthropic's changelog. The dated record is the GitHub releases page, which shows 20 Oct 20:46 beside v2.1.305 and 21 Oct 03:16 beside v2.1.306, with no year and no timezone, and carries the Latest badge on 2.1.306.

#What changed about allowedMcpServers?

The changelog entry is one sentence, and every clause in it matters:

Changed allowedMcpServers to stop filtering managed-mcp.json stdio servers that use ${VAR} only in env: one your allowlist left out now loads on upgrade; use deniedMcpServers to keep it off

The background is in the managed MCP documentation. allowedMcpServers does not normally apply to the servers an organization deploys in managed-mcp.json, with one exception: a server whose definition uses ${VAR} expansion is still checked, "because that server's effective configuration comes from each user's environment rather than from the file alone". The same page lists the fields that trigger that check as a server's "command, arguments, env, URL, or headers". 2.1.305 removes env-only cases from the set, for stdio servers.

This has happened once before, and the documentation still carries the warning from that time:

If you used allowedMcpServers to keep some of your own managed-mcp.json servers from loading, those servers start loading on each user's first launch of v2.1.259 or later unless they use ${VAR} expansion, with no prompt or notice: only deniedMcpServers still subtracts from those servers.

2.1.305 extends that to the env-only ${VAR} servers which v2.1.259 left behind. So the check to run is narrow and specific.

Where to look	What to look for
managed-mcp.json on your fleet	stdio entries ("type": "stdio") whose only ${VAR} reference is inside env
Your allowedMcpServers policy	whether each of those servers matches an entry
Any that do not match	they load after the upgrade unless you add a deniedMcpServers entry

A denylist entry is the documented remedy, and the documentation is explicit that "nothing overrides a denylist match" and that the denylist merges from every settings scope. One caution on how you write it: the same page warns that a serverName entry "is not a security control", because the name is the label a user assigns rather than the underlying server. Use serverCommand or serverUrl for an entry you are relying on.

#One conflict between two Anthropic pages

The managed MCP page, fetched the same day as the changelog, still describes the old behaviour. It states that "a managed-mcp.json server that uses ${VAR} expansion in its command, arguments, env, URL, or headers is still checked", and the settings reference says the allowlist exemption covers "any managed-mcp.json entry whose values use no ${VAR} expansion". The changelog says env-only cases are no longer checked. This article follows the changelog, because it is the newer statement and it describes the release, and notes that the two reference pages had not been updated to match as of 21 October 2026. If you are deciding policy for a fleet, test one server on an upgraded machine rather than trusting either page alone.

#What does sandbox.allowNestedUserNamespaces do?

2.1.305 adds a setting whose own entry describes what it costs:

Added sandbox.allowNestedUserNamespaces so sandboxed commands on Linux can create user namespaces (Chromium, rootless podman); this lets them get around the sandbox's file protections

That is the vendor saying, in the release note itself, that turning this on means sandboxed commands can get past the file protections the sandbox is there to apply. The use cases named are real ones: Chromium and rootless podman both want user namespaces of their own, and both fail inside the Bash sandbox without them.

We could not find the key documented. It is absent from the sandboxing guide and from the sandbox section of the settings reference as those pages read on 21 October 2026, where the nearest key is sandbox.enableWeakerNestedSandbox, documented as a way to "run the Linux sandbox inside an unprivileged Docker container" and described there as reducing security. Treat the changelog line as the specification until a docs page covers it, and prefer the narrower controls the sandboxing guide does document, such as sandbox.excludedCommands for a single tool that cannot work inside the boundary.

#What else is in 2.1.305?

The fix most people will notice is the provider one:

Fixed every request failing on Vertex, Bedrock and other providers when the endpoint or a gateway rejects tool search, and behind gateways with ToolSearch disallowed or left out of --tools (a 2.1.304 regression): Claude Code now retries without it

If you run Claude Code through Vertex AI, Bedrock or a gateway and 2.1.304 stopped working for you entirely, that is the fix, and 2.1.305 or later is the version to move to.

Three more changes are worth knowing before they surprise you, all quoted from the changelog:

Change	What it means for you
"Changed plugins that Claude Desktop mounts by path to no longer keep their allowed-tools when your organization's managed settings set allowManagedPermissionRulesOnly"	A path-mounted plugin that relied on its own allowed-tools starts prompting under that managed setting
"Changed the /artifacts delete confirmation to take 1 or Enter to keep, 2 to delete, and Esc to cancel; y and n no longer answer it"	Muscle memory for y stops working on that one dialog
"Changed a mod's docked pane to stay within 45% of the terminal's width, including a width kept from a wider terminal"	A docked mod pane that used to take more room now stops at 45%

Two additions round out the release. CLAUDE_CODE_RETRY_WATCHDOG_USAGE_LIMIT_RECHECK_MS makes unattended retry mode, CLAUDE_CODE_RETRY_WATCHDOG, notice a usage limit that was lifted before its reset. In VS Code, a "Running start-up hooks" spinner status now shows, with a screen reader announcement, while SessionStart or Setup hooks run.

Code Review picks up two changes in the same release, on top of the review levels that arrived in 2.1.304: it no longer sometimes skips the newest commit when several pushes land during a review, and a re-review no longer opens with LGTM while earlier blocking findings are still open.

#Is 2.1.306 worth upgrading for on its own?

Only if you hit one of its two fixes. The whole release is:

• Fixed claude -p inside cloud sessions reporting "Not logged in" when started without the session's environment variables
• Fixed an API error being replaced by "prompt is too long", and an unneeded compaction, in sessions with many MCP tools

The second one is the interesting half for anyone running a lot of MCP servers, because the symptom hid its own cause: a real API error arrived as a "prompt is too long" message, and the session then compacted for no reason. If you have been seeing unexplained compaction in a session with many tools connected, that is a known bug with a fix rather than something to tune around. What is MCP? covers how those tools reach a session in the first place, and the Claude Code platform hub tracks the rest of the release line.

#What should you do today?

1. If you deploy managed-mcp.json: list the stdio servers whose only ${VAR} reference is in env, check them against your allowedMcpServers policy, and add deniedMcpServers entries for any you want to stay off, before your users upgrade.
2. If 2.1.304 broke Claude Code on Vertex, Bedrock or behind a gateway: upgrade to 2.1.305 or later.
3. If you are tempted by sandbox.allowNestedUserNamespaces: read its own warning first, and reach for the documented narrower controls in the settings and hardening guidance before you widen the sandbox for everything.
4. If you administer permission rules: check whether any path-mounted Claude Desktop plugin in your fleet depended on its own allowed-tools under allowManagedPermissionRulesOnly. Our own settings walkthrough, the best Claude Code settings, covers where those keys live.

Neither release note mentions a model change, a pricing change or a plan change, and we found none on the pages we checked.