Claude Code 2.1.259: managed MCP and tighter permissions

Just one version since the last digest, 2.1.259 from September 2. The official changelog runs past thirty entries, but the thread running through it is clear: this is a release about permissions and managed MCP. Almost everything that matters here is about who gets to run what, and on whose behalf.

A new channel to push MCP to a whole organization

managedMcpServers is a new managed setting: an organization can now provide HTTP or SSE MCP servers to every user, using the same entry shape as a project .mcp.json file. A structural restriction comes with it: an entry that names a command to run is skipped. Only remote servers travel through this channel, never a local process launched by configuration pushed in from outside.

This is a separate mechanism from the already-documented managed-mcp.json file, the one that takes exclusive control of a machine's MCP servers and blocks any other configuration. The managed MCP documentation covers that file and the allowedMcpServers / deniedMcpServers lists that filter what loads. managedMcpServers is a third, lighter option: push a set of servers without imposing the file's exclusive control. If you administer a fleet of Claude Code installs, that's the first thing to check before picking which mechanism to use. They don't substitute for each other the same way.

Two permission adjustments

--permission-prompts none targets headless hosts with nobody around to answer a prompt. Per the changelog, anything that would normally have triggered a prompt is now denied automatically, while the active permission mode, including auto mode, keeps deciding everything else. That's different from dontAsk mode, documented on the non-interactive execution page, which denies anything that doesn't match a permissions.allow rule or the read-only command set. With --permission-prompts none, the auto mode classifier keeps control over what it approves, and only what would have asked a question flips to a denial instead.

The second fix is quieter but wider in reach: Bash Read() deny rules didn't cover files passed as an option value (--ignore-revs-file=.env, -f.env, @file), git diff or git grep file operands, or cd DIR && cat FILE compounds. grep -r or cp -r over a directory holding a denied file now consistently asks for confirmation. The permissions documentation spells out this mechanism's boundary: a Read rule applies "to file commands Claude Code recognizes in Bash, such as cat, head, tail, and sed," not to an arbitrary subprocess that opens a file itself. What got closed here is a set of recognized command forms that still slipped past detection, not the sandbox principle itself: for a guarantee enforced at the system level rather than a deny rule, sandboxing is still the tool to enable.

allowedMcpServers changes scope on upgrade

This one deserves a closer look if you administer machines. allowedMcpServers now governs only servers a user adds themselves. A literal server declared in managed-mcp.json that your allowlist used to filter out starts loading again after the upgrade, without you having touched your configuration. To keep it blocked, add it explicitly to deniedMcpServers, which still merges from every settings scope according to the managed MCP documentation.

This is the kind of change that breaks nothing visibly: no error, no warning, just a server that was filtered starting to respond again. If your allowlist relied on that behavior to strip one specific server out of an otherwise shared managed-mcp.json, go check after upgrading, with claude mcp list on a representative machine.

Concurrent sessions and managed settings: two nets pulled tighter

One fix affects anyone running several Claude Code sessions in parallel on the same machine: concurrent sessions silently reverted each other's changes to ~/.claude.json, resetting the trust granted to a working directory and losing MCP or project state along the way. Nothing visible signaled it, just a session re-asking for trust it had already been given, or losing the connection to a server that had been configured earlier in the same hour.

In a related vein, the documentation confirms a shift in posture on managed settings themselves: "if a managed settings file or drop-in file can't be read or parsed and no other admin source supplies a policy, sessions signed in with claude.ai or Claude Console credentials exit at startup with a message to contact an administrator," the managed settings documentation states. Before, a broken file could leave a security policy simply unenforced with nobody the wiser. The mechanism now chooses to fail closed instead of open.

The rest, in brief

• GitLab: Claude Code now recognizes glab mr create/merge/close/reopen/note/update, showing merge requests as MR !N in the collapsed tool summary and refreshing the footer badge.
• --resume and --continue no longer break on a saved session containing an attachment entry with no payload: the first failed outright, the second opened an empty conversation.
• A custom command or skill's frontmatter model:, previously ignored in interactive sessions, is respected again.
• Worktree-isolated sessions used to refuse common Bash loops, xargs pipelines and launcher-wrapped commands that cannot reach the main checkout.
• An MCP server that disconnects while its tools are being listed at startup now reports the error instead of showing as connected with no tools.
• Stop didn't actually stop background agents and workflows in remote-control sessions: a killed task now stays visible and re-stoppable until its processes exit.
• Remote and scheduled sessions that used to sit idle after a connector-side permission prompt was approved while the session was paused now resume normally.

What to take from this

If you're an individual user, two things actually matter here: the closed Bash gap changes nothing about what you need to do, and the concurrent-sessions bug may explain a folder's trust that seemed to reset itself for no reason. If you administer a fleet, the real work is elsewhere: go check what your allowedMcpServers used to filter out before the upgrade, and what it lets through now, before a server you thought was blocked starts answering again.