macOS: automation Chrome shares bundle id with daily Chrome; CHROME_WS_BROWSER not honored in MCP path

[YoungYo]

Summary

On macOS, chrome-process.js (the code path used by the MCP use_browser tool) always launches the literal /Applications/Google Chrome.app binary — the same bundle the user's everyday browser uses. When automation Chrome instances pile up (see below), macOS's per-bundle "app is running" tracking gets hijacked: clicking the Dock icon / Spotlight-launching "Google Chrome" just activates one of the tool's headless/windowless automation instances instead of opening a real window. To the user this looks exactly like "my browser won't start."

Root cause, in two parts

1. CHROME_WS_BROWSER is documented but not honored in the MCP path.

README.md / COMMANDLINE-USAGE.md document CHROME_WS_BROWSER as overriding auto-detection, and the standalone chrome-ws CLI does read it (chrome-ws:316):

const chromePath = process.env.CHROME_WS_BROWSER || paths.find(p => existsSync(p));

But skills/browsing/lib/chrome-process.js — which is what mcp/dist/index.js actually requires at runtime (require(join(__dirname, "../../skills/browsing/chrome-ws-lib.js")) → chrome-process.js) — never reads it at all. The env var silently does nothing for anyone using the MCP tool (as opposed to the CLI).

2. No way to point automation at a separate Chrome bundle, so it collides with the daily browser.

Because the hardcoded darwin path list only ever contains the main Google Chrome.app, every automation instance (any of superpowers-chrome, -2, -3, ... profiles) shares bundle id com.google.Chrome with the user's regular browser. Combined with instances that never get cleaned up across crashed/closed Claude Code sessions (I found 6 live automation Chrome processes across 4 different profile dirs, one running since 3 days prior, plus 4 separate MCP server node processes going back a week — all still holding old in-memory code via require() caching), the result is that macOS Launch Services considers "Google Chrome" perpetually running, and normal launch attempts just re-activate a headless/invisible instance.

Suggested fix

Minimal patch to skills/browsing/lib/chrome-process.js — honor CHROME_WS_BROWSER (bringing it in line with the CLI and the docs), and prefer a dedicated automation-only Chrome build when present so day-to-day Chrome is never touched by default:

     // --- Step 3: Find Chrome binary ---
     const chromePaths = {
       darwin: [
+        `${os.homedir()}/Library/Caches/superpowers/chrome-for-testing/current`,
         '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
         '/Applications/Chromium.app/Contents/MacOS/Chromium'
       ],
       ...
     };

     const platform = os.platform();
     const paths = chromePaths[platform] || [];

-    let chromePath = null;
-    for (const path of paths) {
-      if (existsSync(path)) {
-        chromePath = path;
-        break;
-      }
+    let chromePath = process.env.CHROME_WS_BROWSER;
+    if (chromePath && !existsSync(chromePath)) chromePath = null;
+    if (!chromePath) {
+      for (const path of paths) {
+        if (existsSync(path)) {
+          chromePath = path;
+          break;
+        }
+      }
     }

(chrome-for-testing/current being a symlink the user/installer points at a @puppeteer/browsers-installed "Google Chrome for Testing.app", which has its own distinct bundle id and therefore never collides with the daily browser's running-app state.)

I've verified this resolution logic in isolation — it correctly prefers the dedicated build when present and falls back to the shared Google Chrome.app otherwise, with no behavior change for anyone who hasn't installed a separate build.

Secondary issue: process leakage across sessions

Separately (and probably deserving its own issue if useful): I found MCP server node processes and their spawned Chrome instances still alive from sessions started 3-7 days earlier, all under different auto-incremented profile names (superpowers-chrome, -2, -3, -4...). Nothing appears to reap these when a Claude Code session ends unexpectedly (vs. a clean chrome-ws kill/shutdown). Over time this silently accumulates background Chrome processes and — per the above — increasingly masks the user's real browser. Happy to file separately if that's preferred.

Environment

• superpowers-chrome 3.0.2 (same code present on main as of this writing)
• macOS, Apple Silicon

[YoungYo]

Opened #41 for the CHROME_WS_BROWSER half of this (the clear-cut bug fix, verified against the full test suite). Left the bundle-id-isolation part here since it's more of a design call than a bug fix — happy to follow up with a PR for that once there's a preferred direction.

[YoungYo]

Update from the reporter, after this bit me again today. Two findings, and the second one unfortunately sinks the Chrome-for-Testing fix I proposed above.

1. The bundle-id collision also breaks open <url> — not just Dock/Spotlight activation

I originally described this as "clicking the Dock icon activates an invisible automation instance." There's a second, more confusing symptom from the same root cause: open https://… from a terminal silently does nothing. It exits 0, and the URL simply vanishes — no tab anywhere.

lsappinfo list shows why. Both Chromes register under com.google.Chrome, and the automation instance can sort ahead of the daily browser:

52) "Google Chrome" ASN:0x0-0x278d78b:   pid = 79680  Version="7871.130"   <- automation instance
71) "Google Chrome" ASN:0x0-0x2b29b27: (in front)     pid = 28422          <- daily browser

Launch Services hands the URL to the automation instance, which was started with --no-default-browser-check and never surfaces it. Things that do not help, for anyone else debugging this: re-selecting the default browser in System Settings (the binding is per bundle id, not per instance), lsregister -f, and open -a "Google Chrome" <url> (still resolves through Launch Services). AppleScript tell application "Google Chrome" to open location "…" does work — it targets the frontmost instance — so that's a usable stopgap.

2. Stale MCP processes hold the old module in memory and defeat the fix

Worth flagging because it silently neutralizes any patch to chrome-process.js: I found node …/mcp/dist/index.js processes 12 and 10 days old, each parented to a claude bg-spare session. They hold the pre-patch module via require() cache, so editing the file on disk changes nothing for them — they keep spawning /Applications/Google Chrome.app with the shared bundle id. Killing just the leaked Chrome isn't enough; a new one reappeared within minutes. You have to kill the stale MCP processes too.

This is the process-leak issue I mentioned at the end of the original report. I'd now rank it above both #40 and #41 — as long as it exists, any launch-path fix can sit on disk fully applied and still not take effect.

3. Why the Chrome-for-Testing approach does not currently work on macOS

I implemented my own suggestion locally and it fails, so I'm not putting it in #41. Two separate problems:

(a) The symlink must point at the .app directory, not the binary. Chrome resolves its Framework relative to the binary's own location, and dyld resolves that against the symlink's directory. Pointing current straight at the binary makes it search <symlink dir>/../Frameworks/ and die:

dlopen(…/chrome-for-testing/../Frameworks/Google Chrome for Testing Framework…): no such file

Nastier than it looks, because existsSync() returns true for that symlink, so the launcher happily selects a path that can never start. Correct form: symlink to …/Google Chrome for Testing.app, then append /Contents/MacOS/Google Chrome for Testing.

(b) Even with the path fixed, the @puppeteer/browsers build can't run CDP on macOS. It's adhoc-signed (Signature=adhoc, TeamIdentifier=not set), so macOS refuses its Mach port rendezvous and every renderer/network child dies at launch:

ERROR mach_port_rendezvous_mac.cc: bootstrap_look_up
  com.google.chrome.for.testing.MachPortRendezvousServer.4147: Permission denied (1100)
ERROR shared_memory_switch.cc: No rendezvous client, terminating process (parent died?)

The HTTP endpoints (/json/version, /json/list) answer fine, which makes it look healthy — but every WebSocket CDP call hangs. Page.enable, Runtime.enable, Runtime.evaluate all time out; the identical client against /Applications/Google Chrome.app succeeds immediately. --no-sandbox doesn't help (2085 rendezvous errors in one launch).

Measured on this machine, npm test:

Chrome binary	Result
/Applications/Google Chrome.app	434 pass / 0 fail
@puppeteer/browsers Chrome for Testing 151.0.7922.34	421 pass / 12 fail

The 12 failures are exactly the real-Chrome smoke tests (dialogs, navigate+extractText, click, fill, selectOption, keyboardPress, screenshot).

Environment: macOS 26 (Darwin 25.5.0), Apple Silicon, Chrome 150.0.7871.186.

So bundle-id isolation via Chrome for Testing needs a properly signed automation build to be viable — an adhoc-signed download isn't enough, at least on recent macOS. I don't know whether Google publishes a signed one, or whether re-signing locally with a Developer ID would satisfy the Mach bootstrap check; I haven't tested either.

Given that, my suggestion would be to treat the process leak (2) as the first thing to fix. It's self-contained, it's what makes the problem recur, and it doesn't require settling the bundle-id design question.

[YoungYo]

Opened #42 for the process-leak half of this. It's the piece that makes the rest of #40 so hard to pin down: leaked servers hold profile locks (pushing each new server onto another profile and another Chrome) and keep serving require()-cached launch code, so a fix can be fully applied on disk and still not take effect.

Scoped narrowly — it stops new leaks, doesn't reap existing orphans, and doesn't touch the bundle-id design question. 436/436, and the new test fails against the unpatched bundle.

[obra]

Two of the three problems here are now fixed on main:

• CHROME_WS_BROWSER honored in the MCP path — PR fix: honor CHROME_WS_BROWSER in the MCP-tool Chrome-launch path #41 merged as 6bbd200, plus a stderr warning when a set-but-missing override is discarded and the override named in the not-found error.
• Process leakage across sessions — PR fix: exit when the host goes away instead of leaking the server process #42 merged as 51bed69: the server exits on stdin EOF / transport close / a 30s ppid watchdog, releasing the profile lock so the next server reclaims the profile and reconnects instead of spawning Chrome N+1.

Still open: the bundle-id collision itself (automation Chrome sharing com.google.Chrome with the daily browser). Per @YoungYo's measurements the @puppeteer/browsers Chrome-for-Testing download is adhoc-signed and can't do CDP on macOS, so a dedicated automation build needs a real signing story — leaving this issue open to track that design question. Meanwhile CHROME_WS_BROWSER now actually works in the MCP path as a manual escape hatch, and the leak fix removes the accumulation that made the collision bite.

— Claude Fable 5, Claude Code 2.1.223