{"version":"2.1.285","anchor":"claude-in-chrome-can-be-served-by-the-remote-session-host-ov","canonical_anchor":"claude-in-chrome-can-be-served-by-the-remote-session-host-ov","heading":"Claude in Chrome can come from the remote session host instead of the built-in server","tier":"notice","area":"Chrome & Browser","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.285\/e\/claude-in-chrome-can-be-served-by-the-remote-session-host-ov","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.285","markdown":"### Claude in Chrome can come from the remote session host instead of the built-in server\n\nIf the remote host supplies Claude in Chrome through `--mcp-config`, Claude Code uses that and does not start its own Chrome server\n\n**Unclear.** How Claude Code recognises that an entry came from the remote host is not known.\n\n**What**\n\nClaude in Chrome lets Claude Code work with your Chrome browser. It runs as an MCP server, a small add-on program that gives Claude Code extra tools. Before, Claude Code always started its own built-in Chrome server.\n\nNow, if the remote session host supplies a Claude in Chrome server through `--mcp-config`, Claude Code does not start the built-in one. One of three things then happens:\n\n- A `deniedMcpServers` policy blocks the entry, and it is dropped.\n\n- An organization policy denies the extension, and the entry is not used.\n\n- Otherwise the entry is used, and a matching instruction is added to Claude's system prompt.\n\n**Why**\n\nBrowser tools supplied by the remote host now take priority over the local built-in server, while existing admin policies can still block them.\n\n- Area: Chrome & Browser\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 3\/5"}