Claude in Chrome versus the built-in Browser pane: crashes, empty browser list, javascript_tool quirks

Claude in Chrome versus the built-in Browser pane

Observed August and November 2026 on Windows 11.

In-app pane can crash the whole app

Starting the built-in Browser pane (mcp__Claude_Browser__preview_start) on a heavy retail site crashed Claude Code itself on one machine. It was not a tab error: the whole app died and would not reopen the page. A later investigation traced one cause of such crashes to a missing MSIX integrity catalog (exit code 0x060C201E); on that machine the pane was safe again after a non-MSIX reinstall.

The fallback is the claude-in-chrome MCP (mcp__claude-in-chrome__*), which drives the real Chrome browser through an extension. Loading the toolkit in a single deferred-tool lookup avoids a round trip per tool:

select:mcp__claude-in-chrome__tabs_context_mcp,mcp__claude-in-chrome__navigate,
mcp__claude-in-chrome__computer,mcp__claude-in-chrome__read_page,
mcp__claude-in-chrome__javascript_tool,mcp__claude-in-chrome__read_network_requests,
mcp__claude-in-chrome__tabs_create_mcp,mcp__claude-in-chrome__tabs_close_mcp

Trade-offs

• Real Chrome carries the real logged-in sessions. That is the point for account-related work, but every action lands on live account state. Authentication and any irreversible click are best left to the human.
• javascript_tool returns [BLOCKED: Cookie/query string data] or [BLOCKED: Sensitive key] for some values, such as URLs with query strings and sessionStorage. Probes that return derived facts (key names, lengths, booleans, JWT claim names) come back fine.
• javascript_tool needs an explicit top-level await (async () => {...})() for async work. A bare async IIFE returns {} because the promise is not awaited.
• The tool suggests browser_batch for multi-step sequences, and that is genuinely faster.

Empty browser list: account mismatch

Observed 11 November 2026: a Claude Desktop Code session ran under one Claude account while the Claude in Chrome extension was signed into a different account. list_connected_browsers returned [] and tabs_context_mcp returned "Claude in Chrome is not connected" on four attempts across three turns. Retrying did not help.

Working theory, not confirmed by a control test: the extension is only visible to a desktop session signed into the same Claude account. The tool's own error text says to "sign in with the same account as this app".

When the list is empty although Chrome is reported as connected, compare the account the session runs under with the account the extension is signed into, rather than retrying. Fallbacks are the built-in browser pane with the human signing in, or the human exporting the data to a file.