Unclear It is not clear whether the earlier check covered any case besides deniedMcpServers.
What
Claude in Chrome is the browser integration, delivered as a built-in MCP server (MCP is a standard for connecting outside tools). Organizations that deploy a managed MCP configuration, managed-mcp.json, take exclusive control of which MCP servers run, and that used to block Claude in Chrome with no way to allow it.
- A new device policy key,
allowClaudeInChromeWithManagedMcp, is off by default. When it is true and the enterprise configuration was read without fatal errors, Claude in Chrome can run alongsidemanaged-mcp.json.deniedMcpServersand the organization's Claude in Chrome setting can still block it. - Without the key, trying to configure Chrome is refused with a Chrome-specific message: "Claude in Chrome is blocked by your organization's managed MCP configuration (managed-mcp.json). An administrator can allow it with allowClaudeInChromeWithManagedMcp in device policy." Before, it got the generic "You cannot dynamically configure MCP servers when an enterprise MCP config is present" message.
- The prompt offering to install or set up Claude in Chrome is now also skipped when
managed-mcp.jsonblocks Chrome. Before, onlydeniedMcpServerswas checked. - Starting Remote Control with
--chromeunder a blocking policy now prints the specific reason Chrome is blocked, followed by "Start Remote Control without --chrome." It used to print one fixed message naming both an enterprise MCP config and adeniedMcpServersentry.
Why
Administrators using managed-mcp.json can now opt in to Claude in Chrome. Where it stays blocked, people are no longer offered a setup that cannot work, and error messages name the policy responsible.
It is not clear whether the earlier check covered any case besides `deniedMcpServers`.
Added the allowClaudeInChromeWithManagedMcp managed setting to let claude --chrome run alongside an exclusive managed-mcp.json; the error…