tl;dr Claude Code’s /chrome has a hard-coded browser priority list that picks Brave over Edge, with no config override. On macOS, move /Applications/Brave Browser.app to ~/Applications/ and Claude Code falls through to your preferred browser. Brave still works fine from there.

I created this article, but it has been reviewed and refined with help from AI tools: Claude and Grammarly.

You install the Claude in Chrome extension in Edge. Edge is your default and already running. You type /chrome in Claude Code, hit “Reconnect extension”, and Brave launches - a browser where the extension isn’t even installed.

I hit this today. The fix is simple once you see it, but the root cause is worth writing down.

What the docs claim

Per the Claude Code Chrome integration docs:

“Chrome integration is in beta and currently works with Google Chrome and Microsoft Edge. It is not yet supported on Brave, Arc, or other Chromium-based browsers.”

So Brave is explicitly unsupported. Fine. You’d therefore expect Claude Code to refuse to touch Brave at all, or at minimum to prefer any supported browser over any unsupported one. Neither of those is true.

What actually happens

Claude Code ships as a self-contained binary at ~/.local/share/claude/versions/<version> on macOS. If you extract strings out of that binary, there’s a hard-coded browser priority list and a corresponding config map. The relevant JavaScript, reconstructed from the minified bundle, looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

const BROWSERS = {
  chrome:   { macos: { appName: "Google Chrome" },    ... },
  brave:    { macos: { appName: "Brave Browser" },    ... },
  arc:      { macos: { appName: "Arc" },              ... },
  chromium: { macos: { appName: "Chromium" },         ... },
  edge:     { macos: { appName: "Microsoft Edge" },   ... },
  vivaldi:  { macos: { appName: "Vivaldi" },          ... },
  opera:    { macos: { appName: "Opera" },            ... }
};

const PRIORITY = ["chrome", "brave", "arc", "edge", "chromium", "vivaldi", "opera"];

for (const id of PRIORITY) {
  const b = BROWSERS[id];
  const appPath = `/Applications/${b.macos.appName}.app`;
  try {
    if ((await fs.stat(appPath)).isDirectory()) {
      return b;   // first match wins, stop looking
    }
  } catch {}
}

And when it’s time to actually open a URL:

1

await execFile("open", ["-a", browser.macos.appName, url]);

Read the priority list carefully. Brave is position 2. Edge is position 4. It’s first-match-wins, so if Google Chrome isn’t installed (it isn’t on my machine) and Brave is (it is, because I keep it around for a few sandboxed things), Brave wins and Edge is never even considered. The system default, the running process list, and which browser actually has the extension - none of it is consulted.

The detection is a single fs.stat("/Applications/Brave Browser.app") call. It doesn’t check ~/Applications/. It doesn’t check whether Brave has the extension. It doesn’t check the system default browser. It just stats /Applications/ and picks the first one that exists.

The launch uses open -a "Brave Browser", which goes through macOS Launch Services and resolves the bundle by name, not by path.

I looked for a config override. There isn’t one.

Before accepting the fix below, I checked every obvious lever:

  • claude --help and CLI flags: no --browser, no --chrome-browser.
  • Environment variables: I grepped the binary for CLAUDE_CHROME_BROWSER, CLAUDE_BROWSER, BROWSER_ID, --browser, and nothing exists.
  • ~/.claude/settings.json: no browser preference key is documented or honoured.
  • The /chrome command’s interactive menu: shows Enable/Disable, Manage permissions, Reconnect, and Enabled by default. No browser selector.

This is also tracked upstream as anthropics/claude-code#14536 - “Allow browser selection instead of opening default browser” - open, 13+ comments, no fix at the time of writing. One commenter notes the same symptom I saw: “this happens EVEN when I’ve set chrome as my default browser lolol”. Confirmed by reverse engineering: the system default browser is never consulted.

Things that don’t work

Before landing on the real fix, I tried a few things that look like they should work but don’t:

  • Deleting the Brave native messaging host manifest at ~/Library/Application Support/BraveSoftware/Brave-Browser/NativeMessagingHosts/com.anthropic.claude_*.json. Claude Code just rewrites it on the next /chrome invocation. And even if you lock the file as empty with chflags uchg, Claude Code still picks Brave - the selection happens before (and independently of) the manifest write.
  • Restarting Claude Code. No effect. The priority list is hard-coded.
  • Making sure Edge is already running with the extension loaded. No effect. Claude Code never asks the running process list.
  • Setting Edge as the macOS default browser. Already was. Claude Code doesn’t care.

The only state Claude Code inspects on macOS to decide which browser to launch is fs.stat("/Applications/<AppName>.app") for each entry in the priority list, in order.

The fix that actually works

Since the detection only checks /Applications/, move Brave to ~/Applications/. macOS has supported ~/Applications/ as a user-level app install location forever; Launch Services will still find Brave and open -a "Brave Browser" still works, so Brave itself keeps functioning normally. But Claude Code’s detection loop fails on Brave, falls through Arc (which I don’t have), and lands on Edge - which is what we wanted all along.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Quit Brave first if it's running
osascript -e 'quit app "Brave Browser"'

# Create ~/Applications if it doesn't already exist
mkdir -p ~/Applications

# Move Brave out of /Applications
mv "/Applications/Brave Browser.app" ~/Applications/

# Re-register with Launch Services so `open -a "Brave Browser"` still finds it
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -f ~/Applications/Brave\ Browser.app

Then restart Claude Code, run /chrome, and “Reconnect extension”. Edge opens. The extension connects. tabs_context_mcp starts returning Edge tabs.

Reverse any time with mv ~/Applications/Brave\ Browser.app /Applications/ and another lsregister -f.

A sanity check before you reconnect

1
2
3
4
5
6
7
8

# Should fail with "No such file or directory"
stat "/Applications/Brave Browser.app"

# Should print a valid directory
stat ~/Applications/Brave\ Browser.app

# Should resolve to the new ~/Applications path
osascript -e 'tell application "Finder" to get POSIX path of (application file id "com.brave.Browser" as alias)'

If the first command errors, the second prints a stat block, and the third prints /Users/<you>/Applications/Brave Browser.app/, you’re good. Open Claude Code, run /chrome, pick Reconnect, click Connect in the Edge toolbar when it prompts you.

Wrapping up

This is a rough edge in a beta feature, and I’m hopeful Anthropic will either flip edge ahead of brave in the priority list (one-line fix), drop brave from the list entirely (it’s explicitly not supported per their own docs), or expose a claudeInChromeBrowser settings key. Any of those would make this disappear.

Until then, the ~/Applications/ move is the cleanest workaround I’ve found. It doesn’t require renaming Brave, doesn’t require uninstalling anything, doesn’t require patching the Claude Code binary (which auto-updates and would clobber any patch), and doesn’t break Brave itself. It exploits the fact that Claude Code’s detection is narrower than macOS’s own app discovery.

If you hit this on Windows or Linux, the same logic applies - Claude Code iterates the same hard-coded list, stats a platform-specific path per browser, and picks the first match. The exact workaround differs (Windows uses HKCU\Software\<Vendor> keys; Linux scans PATH for binaries named in the config), but the strategy is the same: move the app out of whatever directory Claude Code scans first, while keeping it runnable via the OS’s normal launcher.

If you’re also annoyed by this, give anthropics/claude-code#14536 a thumbs up so it climbs the backlog.

Thanks for reading.