Claude Code 2.1.259 hands MCP servers to the whole org

Claude Code 2.1.259, released September 2, adds a managed setting called managedMcpServers. It lets an organization push a set of remote MCP servers to every user without removing the servers users add themselves. The same release narrows what allowedMcpServers controls, and that can change which servers load once you upgrade.
The release notes on GitHub list more than thirty other changes. Several matter to anyone running Claude Code unattended: a flag that turns every permission prompt into a denial, a fix for Bash deny rules that let some file reads through, and a fix for concurrent sessions overwriting each other’s state.
A third way to hand out servers
By default, anyone running Claude Code can connect any MCP server they like. Anthropic reviews connectors before listing them in its directory, but it doesn’t security-audit or manage MCP servers. Until now an admin had two ways to rein that in, and the Claude Code documentation on managed MCP now lists three patterns. A managed-mcp.json file deploys a fixed set of servers. allowedMcpServers and deniedMcpServers filter the servers users configure. The new managedMcpServers setting provides servers alongside the user’s own. The docs call this last pattern “Provided servers”: every user gets the remote servers the admin lists and keeps their own.
Entries use the same shape as .mcp.json, so a server block from a project config can be copied over as is. The setting only accepts HTTP and SSE servers, the two transports that talk to a server over the network. An entry that names a command to run, which would be a local stdio server that Claude Code launches as its own process, is skipped. An admin can hand every user an endpoint this way, but not a binary to execute.
The other reason the setting exists is delivery. managed-mcp.json is a standalone file, so it can’t be delivered through server-managed settings. Organizations that push policy that way had no route for MCP servers that didn’t involve putting a file on every machine. managedMcpServers sits inside managed settings, so it travels with the rest of the policy.
The two mechanisms differ in how much control they take. Once a managed-mcp.json is deployed, Claude Code loads only the servers that file defines, the servers provided through managedMcpServers, in-process servers registered by the app that started the session (such as the VS Code extension’s server or the desktop app’s connectors), and the built-in Claude in Chrome server if it’s allowed. Users can’t add, modify or use anything else, including servers that come with plugins and servers passed with --mcp-config. managedMcpServers on its own leaves user configuration alone.
Headless hosts and deny rules
--permission-prompts none targets hosts that run Claude Code with nobody watching. Anything that would have produced a prompt is denied automatically. The active permission mode, auto mode included, still makes its decisions, so what the mode would allow on its own still runs, and only the requests that would have waited for a human get refused.
That flag sits next to a fix for Read() deny rules applied to Bash commands. The rules didn’t cover files passed as option values (--ignore-revs-file=.env, -f.env, @file), file operands to git diff and git grep, or compound commands like cd DIR && cat FILE. All of those could read a denied file. Now grep -r or cp -r over a directory that holds a denied file triggers a prompt. On a host running with --permission-prompts none, that prompt becomes a denial.
The third fix in this group affects anyone who runs many sessions at once. Concurrent sessions were silently reverting each other’s changes to ~/.claude.json, which reset workspace trust and lost MCP and project state. Worktree-isolated sessions also stop refusing common Bash loops, xargs pipelines and launcher-wrapped commands that can’t reach the main checkout. They also accept worktrees created by hooks on machines where git rev-parse fails with a message other than “not a git repository”.
Policy that fails loudly
Before this release, if Claude Code couldn’t parse the managed settings file, a drop-in, the MDM plist or the HKLM registry value, it started anyway and the policy went unenforced without any warning. Now it refuses to start and names the source that failed to parse. Two smaller fixes are in the same area. A managed forceRemoteSettingsRefresh was ignored at startup if a policy helper configured through MDM or the managed settings file had already run. OpenTelemetry metrics and events from cloud sessions were missing the user.email, organization.id and user.account_uuid attributes.
Smaller changes
GitLab users get first-class treatment in two places. Claude Code now recognizes glab mr create, merge, close, reopen, note and update, so merge requests show as MR !N in the collapsed tool summary and update the MR badge in the footer. /install-github-app run inside a GitLab repository now explains that it only works with GitHub and points to the GitLab CI/CD docs. Also in this release:
claude plugin validate --jsonproduces a machine-readable validation report.- A conversation whose thinking was rejected once no longer gets rejected on every later turn.
- The prompt cache no longer resets when the OAuth token refreshes in sessions with telemetry disabled.
- Blocking Stop hooks no longer drop the model’s reasoning from the turn after the block, which on some models also caused a prompt cache miss.
model:in the frontmatter of custom commands and skills is now respected in interactive sessions. In auto mode, a turn stays on the session model instead of switching to one auto mode doesn’t support.--resumeand--continuework again on saved sessions that contain an attachment entry with no payload.- Remote claude.ai sessions no longer wait 60 seconds to start a turn after the page of a browser-hosted MCP server has closed. In headless and SDK sessions, the first turn starts up to 50 ms sooner once MCP servers finish connecting.
- Stop now actually stops background agents and workflows in remote-control sessions, and resuming a workflow while its previous run is still exiting no longer starts duplicate agents.
- The VS Code session list adds an Active quick filter and a status filter menu: Needs input, Working, Completed.
Check the allowlist before upgrading
One change in this release can turn a server on without anyone editing a config. allowedMcpServers now governs only servers that users add. Previously, an allowlist could also filter out a server listed literally in managed-mcp.json. After the upgrade, that server loads. The allowlist has had other gaps: a GitHub issue filed against version 2.1.70 reported that allowedMcpServers in managed settings could be bypassed by passing --mcp-config and --allowedTools at startup. The reporter found that managed-mcp.json blocked --mcp-config correctly and used it as the workaround.
For a managed server that was meant to stay blocked, the fix the release notes give is to list it in deniedMcpServers.
Up next
Claude’s commerce blueprint ships two reference agents
Carts up to 35% larger and shoppers 60% more likely to buy, that’s what Anthropic reports from retailers with shopping agents on Claude. The blueprint behind them ships today as a forkable repo.
Related stories
- Claude Code 2.1.265 loads a whole folder of plugins
- Claude Code 2.1.261 prunes skills that eat context
- Claude Code 2.1.260 opens a live diff panel
- Claude Code 2.1.247 drafts its own feedback reports
- Claude Code 2.1.251 streams subagent work live
- In Claude Code, one CLAUDE.md silently kills your AGENTS.md
Comments
No comments yet. Be the first.
Join the conversation
Sign in to leave a comment. It appears after moderation.

