[BUG] v2.1.141 regression: enterprise managed-mcp.json blocks Claude-in-Chrome dynamic MCP setup (worked in 2.1.140)

TL;DR

In v2.1.141, interactive claude fails to start with You cannot dynamically configure MCP servers when an enterprise MCP config is present whenever Claude-in-Chrome is enabled and a /Library/Application Support/ClaudeCode/managed-mcp.json is deployed.

Same setup on v2.1.140 starts cleanly. The interlock that rejects user-defined dynamic MCP servers under enterprise policy is now also catching the built-in Claude-in-Chrome MCP setup, which seems unintended.

Environment

• Claude Code 2.1.141 (auto-updated 2026-05-13 19:55 PT; broke 12 hours later)
• macOS, Apple Silicon (Darwin 25.1.0)
• Native install (~/.local/share/claude/versions/2.1.141, Mach-O ARM64)
• Enterprise managed-mcp.json present at /Library/Application Support/ClaudeCode/managed-mcp.json (root-owned, deployed by org)
• managed-settings.json does not define allowedMcpServers / deniedMcpServers
• Claude-in-Chrome paired and enabled (claudeInChromeDefaultEnabled: true, cachedChromeExtensionInstalled: true)

Reproduction

1. Deploy a /Library/Application Support/ClaudeCode/managed-mcp.json containing one or more mcpServers (no allowedMcpServers field).
2. Enable Claude-in-Chrome (pair extension; claudeInChromeDefaultEnabled: true ends up in ~/.claude.json).
3. Run claude from a TTY.

Expected (matches v2.1.140 behavior): TUI starts; the enterprise-managed MCP servers load; Claude-in-Chrome MCP also registers.

Actual (v2.1.141): prints

You cannot dynamically configure MCP servers when an enterprise MCP config is present

and exits before the TUI renders. claude --print is unaffected because the one-shot path skips Chrome MCP setup.

Diagnosis

The error string and surrounding code path exist in both v2.1.140 and v2.1.141 binaries (verified via strings). The control flow in both:

// after setupClaudeInChromeMCP() merges into the mcpConfig accumulator
if (hasEnterpriseMcpConfig()) {
  if (strictMcpConfig)                   return error("...--strict-mcp-config...")
  if (mcpConfig && !isAllowedUnderPolicy(mcpConfig))
                                         return error("...dynamically configure MCP...")
}
// then ComputerUse MCP setup follows

In v2.1.140, isAllowedUnderPolicy(mcpConfig) returns truthy for the Claude-in-Chrome bundle and startup proceeds. In v2.1.141 it returns falsy and startup aborts. The validator was tightened between releases — most likely intending to clamp down on user-supplied dynamic servers, but unintentionally now also rejects the built-in Chrome (and presumably Computer Use) MCP setup.

The minified identifiers differ between versions but the surrounding logic is structurally identical, so the change is inside isAllowedUnderPolicy (lG7 in 2.1.140 → uk7 in 2.1.141), not in the call sites.

Workaround

• claude --no-chrome starts (disables Claude-in-Chrome integration)
• Rolling back to 2.1.140 starts cleanly with Chrome enabled (verified via TTY test using script(1))

I've pinned my install to 2.1.140 and disabled autoUpdates until this is resolved.

Suggested fix

Claude-in-Chrome and Computer Use MCP setup should be classified as built-in / first-party rather than scope:"dynamic", or the enterprise interlock should explicitly allow them. A user enabling Claude-in-Chrome on a managed device is not the same scenario as --mcp-config user.json or programmatic claude mcp add — the policy gate should distinguish.

Related

• #40559 — Enterprise managed-mcp.json silently blocks claude.ai cloud connectors (different symptom, same gate)
• #39361 — Desktop app crashes on managed-mcp.json (different surface)
• Cluster of v2.1.141 MCP regressions: #58924, #58947, #58909