Support configurable Chrome binary path for --chrome flag

Status Fixed / completed

Maintainer reply None cached

Activity 4 comments · opened Mar 14, 2026 · closed Mar 15, 2026

Summary

The --chrome / /chrome integration currently hardcodes "Google Chrome" as the browser application name on macOS (via open -a "Google Chrome"). This makes it impossible to use Chrome Canary or other Chromium-based browsers with the Chrome integration feature.

Current Behavior

Claude Desktop App uses hardcoded open -a "Google Chrome" to launch the browser
The native messaging host config can be copied to Chrome Canary's NativeMessagingHosts/ directory
The Claude in Chrome extension can be installed in Chrome Canary
But /chrome always launches regular Google Chrome, ignoring Canary

Expected Behavior

Users should be able to configure which Chrome-based browser is used for the --chrome integration. Options could include:

A setting in settings.json (e.g., "chromeBinary": "Google Chrome Canary")
An environment variable (e.g., CLAUDE_CHROME_APP="Google Chrome Canary")
Auto-detection of available Chrome variants with preference ordering

Environment

macOS (Darwin 25.3.0)
Claude Code CLI + Claude Desktop App
Both Google Chrome and Google Chrome Canary installed
Native messaging host config present for both browsers
Claude in Chrome extension installed in Chrome Canary

Workaround

Currently none that fully works. The hardcoded path in the app binary (/Applications/Claude.app/Contents/Resources/app.asar) prevents redirection to Canary.

🤖 Generated with Claude Code

View original on GitHub ↗

4 Comments

stolot0mt0m · 7 months ago

Same frustration here — having to use regular Chrome when Canary is your daily driver feels unnecessarily limiting.

For the native messaging manifest side of things, I built a setup tool that handles this for Chrome Canary (and 27+ other Chromium browsers) across all platforms: https://github.com/stolot0mt0m/claude-chromium-native-messaging — it auto-detects Canary at the correct paths (Google/Chrome Canary on macOS, google-chrome-unstable on Linux, Chrome SxS on Windows).

That said, even with the manifests in place, the open -a "Google Chrome" hardcoding in the app is the real blocker. An env var like CLAUDE_CHROME_APP would be the clean solution. Hopefully this gets picked up — it'd make life easier for a lot of people.

stolot0mt0m · 7 months ago

Adding context from our analysis: the hardcoded open -a "Google Chrome" is only half the problem.

The MCP tool calls go through wss://bridge.claudeusercontent.com, not local sockets. The Chrome extension connects to this bridge, but only when a server-side feature flag (chrome_ext_bridge_enabled) allows it — which it currently doesn't for non-Chrome browsers.

So even if the binary path were configurable, Chrome Canary (or any other Chromium browser) still wouldn't work for /chrome MCP tools unless the bridge feature flag is unlocked for that browser too. Detailed analysis: #34364

rolpro · 7 months ago

@stolot0mt0m Forget the antrophic one. Just eats tokens.
I found a nice one that does way more, faster and without using any tokens: https://github.com/pasky/chrome-cdp-skill

This one even has the ability to switch browsers in the prompt: https://github.com/seahyc/chrome-cdp-skill/tree/feat/multi-browser (branch of @seahyc's fork)

Works like a charm!

github-actions[bot] · 6 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.