Claude Code 2.1.259: Org-Level MCP Server Push and the Concurrent Session State Fix Operators Missed

Claude Code 2.1.259 is the release that changes how organizations deploy MCP servers — and it does so by breaking a filter your fleet may already rely on.

Two items in this changelog have immediate operator consequences. First: managedMcpServers, a new managed setting that lets an org push HTTP/SSE MCP servers to every user without asking them to configure anything. Second: the fix for concurrent sessions silently reverting each other's ~/.claude.json — a bug that was quietly corrupting workspace trust state and MCP configuration in multi-agent and CI environments for any team running more than one Claude Code session at a time.

A third item closes a gateway proxy gap: CLAUDE_CODE_MAX_CONTEXT_TOKENS was being silently ignored for Vertex-style model IDs that include an @YYYYMMDD suffix — the exact format used by versioned model aliases on Vertex AI.

The change that reshapes org-level MCP rollout

managedMcpServers is a new field in the managed settings file (the HKLM/MDM/managed-settings.json policy layer). An admin sets it once; it propagates to every user's session at startup, same as other managed settings.

The critical constraint: only HTTP/SSE MCP servers are accepted. Any entry that specifies a command to run locally is skipped silently. This is not a bug — it is an intentional security boundary. The managed layer is for remote servers your org operates and controls, not for spawning local processes on user machines from an admin config.

The entry shape mirrors .mcp.json for HTTP/SSE entries:

{
  "managedMcpServers": {
    "corp-tools": {
      "type": "http",
      "url": "https://mcp.your-corp.internal/tools"
    }
  }
}

This is the first time admins can guarantee a specific MCP server is present in every session without relying on users to run claude mcp add or maintain a local config file. For teams that operate internal tool servers — code search, ticketing, internal docs — the deployment path is now policy-level rather than per-user onboarding.

What the allowedMcpServers migration break actually does to your fleet

The behavior change that will catch operators off guard is in allowedMcpServers.

Before 2.1.259: if a managed-mcp.json file existed and allowedMcpServers was set, the allowlist filtered managed servers too. A managed server not on the allowlist would not load.

After 2.1.259: allowedMcpServers only governs servers that users add. Servers in managed-mcp.json load unconditionally on upgrade, regardless of the allowlist.

If your org used allowedMcpServers as the gate for controlling which managed servers were active — a configuration that worked before this release — it no longer does. The migration path is explicit: move that control to deniedMcpServers. Any server you want to keep off gets listed there; the allowlist is now user-MCP-only.

For teams that had allowedMcpServers: [] as a lockdown posture (blocking all user-added servers while allowing managed ones), the behavior is unchanged. But for any config that had specific managed server names in the allowlist as a filter, those entries are now inert for managed servers.

The concurrent session state corruption that was silently eating CI runs

The bug: when multiple Claude Code sessions ran simultaneously and wrote to ~/.claude.json, they silently reverted each other's changes. Workspace trust grants made in one session would disappear by the time another session finished. MCP server registrations added mid-run would be lost. Project state written by a parallel agent would be overwritten.

This is not a hypothetical edge case. Any CI pipeline running parallel Claude Code agents — PR review bots, automated test generation, multi-agent coding workflows — was subject to this. The failure mode is especially hard to debug because ~/.claude.json writes don't fail or log an error; the last writer simply wins, and earlier writes vanish silently.

The fix serializes writes to ~/.claude.json. For operators running multi-agent pipelines, this means workspace trust grants, MCP registrations, and project state accumulated during a run should now survive through the session lifecycle without needing custom locking or a shared-state workaround.

Vertex model ID configuration operators got wrong

CLAUDE_CODE_MAX_CONTEXT_TOKENS was silently ignored for model IDs with an @YYYYMMDD suffix — the format Vertex AI uses for pinned model versions such as claude-fable-5-1@20260901.

Claude Code didn't recognize these as known model versions and skipped the token limit override. On a gateway proxy that routes to Vertex using versioned aliases, this meant context window limits were falling back to defaults even when the env var was set. Teams with cost control or prompt budget policies enforced through CLAUDE_CODE_MAX_CONTEXT_TOKENS were getting no enforcement on Vertex-pinned model IDs.

The fix extends the model ID matching to cover @YYYYMMDD-suffixed identifiers. If you run a gateway proxy that forwards Claude Code sessions to Vertex with pinned model versions, verify the token limit is now being applied.

What to audit and configure now

Four concrete things to check after upgrading to 2.1.259:

1. Review your allowedMcpServers usage. If you have managed MCP servers and were relying on allowedMcpServers to gate which ones loaded, switch that logic to deniedMcpServers before rolling out 2.1.259. The allowlist no longer governs managed entries.

2. Decide on managedMcpServers. If your org operates internal HTTP/SSE MCP servers, this is the time to move them into the managed layer. The benefit: users don't need to configure them manually, and the servers can't be accidentally removed from a local config edit.

3. Audit multi-agent CI pipelines. If you were working around the concurrent write bug with custom locking, shell serialization, or session sequencing, you can simplify those workarounds. Test the new behavior in a staging environment before removing lockout logic entirely.

4. Check Vertex model alias configurations. If you proxy Claude Code to Vertex using @YYYYMMDD model IDs and have CLAUDE_CODE_MAX_CONTEXT_TOKENS set, verify that the token limit is now being honored. A quick test: run a session against a known Vertex versioned alias and confirm the context window cap is applied.

What TheRouter users should watch or try

The managedMcpServers and deniedMcpServers changes operate at the Claude Code policy layer, upstream of any gateway. The gateway sees these sessions the same way regardless of which MCP servers are present.

Where a gateway becomes relevant: if your managedMcpServers entries point to internal HTTP/SSE servers, those servers need to be reachable from the agent's network context. Teams using TheRouter as the outbound request gateway should verify that MCP server URLs are either routed through the gateway or excluded from it, depending on whether they're internal or external endpoints.

The Vertex @YYYYMMDD fix is relevant to any team using TheRouter to proxy Claude Code traffic to Vertex AI. If your gateway forwards requests to versioned Vertex model aliases, context window enforcement via CLAUDE_CODE_MAX_CONTEXT_TOKENS should now work correctly end-to-end. Check your routing configuration if you've been seeing unexpected context limit behavior on Vertex-pinned models.