feat: Add env var for custom Chromium browser path

While waiting for the CLAUDE_CODE_CHROME_PATH env var, I created a workaround that configures Native Messaging Host for alternative browsers:

🔗 https://github.com/stolot0mt0m/claude-chromium-native-messaging

This enables Claude Desktop and Claude Code integration with Brave, Arc, Vivaldi, Edge, Genspark, and other Chromium-based browsers by creating the necessary manifest files.

Works on macOS and Linux. The script auto-detects installed browsers and lets you choose which ones to configure.

Heads up — we analyzed the /chrome architecture and found that CLAUDE_CODE_CHROME_PATH alone wouldn't fix the problem.

The MCP integration doesn't use local sockets for tool calls. It communicates entirely through wss://bridge.claudeusercontent.com. The extension connects to this bridge, Claude Code's MCP server connects to the same bridge, and they're matched by user account. The catch: the extension only opens the bridge WebSocket when a server-side feature flag (chrome_ext_bridge_enabled) returns true — which it doesn't for non-Chrome browsers.

Full analysis with evidence: #34364

An env var for the browser binary path would help with the "launch" side (opening the right browser), but without the bridge feature flag being unlocked for non-Chrome browsers, the MCP server still won't find the extension.

+1 on this. I'm using Helium (ungoogled-chromium based) as my daily browser on macOS. The Claude extension works perfectly in Helium, and I've already set up the native messaging host manifest manually in ~/Library/Application Support/net.imput.helium/NativeMessagingHosts/, but Claude Code's /chrome command still tries to launch Google Chrome instead of detecting Helium.

Even though Helium is my system default browser (net.imput.helium is registered as the http handler), Claude Code doesn't recognize it as a valid Chromium browser.

A CLAUDE_CODE_CHROME_PATH env var would solve this cleanly. Would love to see this shipped.

@daiver18 you should check out this comment

where @rolpro mentioned these two options which do work:

• https://github.com/pasky/chrome-cdp-skill
• https://github.com/seahyc/chrome-cdp-skill/tree/feat/multi-browser (branch of @seahyc's fork)

2nd one even has the ability to switch browsers in the prompt.

Another Helium data point, with the detection path traced end to end — and the outcome is a bit different from what this thread assumes: the integration already works in Helium. Only the reporting is broken.

Setup: macOS, Helium (ungoogled-chromium fork, ~/Library/Application Support/net.imput.helium/), Claude Code 2.1.220, extension fcoeoabgfenejglbffodgkkbkcdhcgfn v1.0.81.

The extension works — /chrome just says otherwise

Before changing anything, browser automation was fully functional. list_connected_browsers returned a live local browser, and creating a tab opened a real window in Helium. Every mcp__claude-in-chrome__* tool worked.

Meanwhile /chrome printed, in the same panel:

Extension: Not detected
Browser:   Browser 1

Those two lines contradict each other. Claude Code knows a paired browser exists — it names it — and still reports the extension as missing, which also greys out "Manage permissions" and "Reconnect extension".

Why: detection is a filesystem scan against a hardcoded allowlist

Detection never looks at the bridge. It walks a fixed browser list:

["chrome", "brave", "arc", "edge", "chromium", "vivaldi", "opera"]

maps each to a fixed base path, then for every Default / Profile * directory does a readdir on <basePath>/<profile>/Extensions/<extensionId>. First successful readdir wins; otherwise "Extension not found in any browser".

Helium has no entry in that table, so its directory is never examined. No amount of restarting, reinstalling, or new sessions can change the result.

Two things that did NOT help

• Installing the native messaging host manifest into Helium. Copying com.anthropic.claude_code_browser_extension.json into ~/Library/Application Support/net.imput.helium/NativeMessagingHosts/ changed nothing, since detection never consults it. (Same result @daiver18 reported above.)
• Restarting the browser and starting a fresh session.

What did work — and what it proves

Symlinking Helium's extension directory into an unused allowlisted path:

~/Library/Application Support/Chromium/Default/Extensions/fcoeoabgfenejglbffodgkkbkcdhcgfn
  -> ~/Library/Application Support/net.imput.helium/Default/Extensions/fcoeoabgfenejglbffodgkkbkcdhcgfn

/chrome immediately flipped to Extension: Installed and unlocked both menu entries.

The point isn't the workaround — it's what the experiment isolates. Nothing about the actual connection changed. Browser automation behaved identically before and after. The symlink only satisfies a readdir that gates a status string. Detection and connection are entirely independent code paths, and the status line reports the wrong one.

Implications for the proposal in this issue

This supports @stolot0mt0m's point that CLAUDE_CODE_CHROME_PATH alone wouldn't be sufficient — but the reason is that for already-paired browsers, there is nothing left to fix on the connection side. The bridge pairs by account and is browser-agnostic; it works in Helium today. What's missing is only that local detection can't see it.

Two changes worth considering, roughly in order of effort:

1. Trust the bridge for status. If a browser is paired and tools are live, don't print Extension: Not detected, and don't gate "Manage permissions" / "Reconnect extension" behind a filesystem probe. This alone resolves the user-visible problem for every unlisted Chromium fork.
2. Make the scan generic. Instead of an allowlist of base paths, glob ~/Library/Application Support/*/{Default,Profile *}/Extensions/<extensionId> (plus the Linux/Windows equivalents). The extension ID is the actual signal — the browser's name isn't. This is what #14370 solved by extension rather than by generalization, which is why Dia (#36410) and Helium keep resurfacing.

Happy to provide further detail from this setup if useful.