Summary

chrome-devtools-mcp --autoConnect appears incompatible with the default Chrome profile on macOS after Chrome 136+ remote-debugging hardening.

On this machine, live attach to the real signed-in Chrome session fails consistently with:

Could not find DevToolsActivePort for chrome at /Users/michael/Library/Application Support/Google/Chrome/DevToolsActivePort

But launching Chrome with a non-default --user-data-dir works immediately, which suggests the current autoConnect path is still relying on default-profile DevToolsActivePort discovery that Chrome no longer honors.

Environment

• macOS 26.4
• Node 22.22.0
• Google Chrome 147.0.7727.56
• chrome-devtools-mcp 0.21.0

Relevant Chrome change

Chrome announced on March 17, 2025 that --remote-debugging-port / --remote-debugging-pipe are no longer respected for the default Chrome data dir and require a non-standard --user-data-dir:

• https://developer.chrome.com/blog/remote-debugging-port

Chrome later documented the permission-based live-session MCP flow here:

• https://developer.chrome.com/blog/chrome-devtools-mcp-debug-your-browser-session

Repro

Failing path: default profile

1. Start normal Google Chrome using the default profile.
2. Enable remote debugging in chrome://inspect/#remote-debugging.
3. Run:

npx -y chrome-devtools-mcp@latest --autoConnect

Observed:

• attach fails with Could not find DevToolsActivePort ...
• no listener appears on 127.0.0.1:9222
• after a clean restart, no fresh ~/Library/Application Support/Google/Chrome/DevToolsActivePort is created

Control test: non-default profile works

Run:

open -na "Google Chrome" --args \
  --remote-debugging-port=9333 \
  --user-data-dir=/tmp/openclaw-chrome-debug-profile \
  --no-first-run \
  --no-default-browser-check \
  about:blank

Then:

lsof -nP -iTCP:9333 -sTCP:LISTEN
curl http://127.0.0.1:9333/json/version

Observed:

• Chrome listens on 127.0.0.1:9333
• /json/version returns valid DevTools metadata

Example:

{
  "Browser": "Chrome/147.0.7727.56",
  "Protocol-Version": "1.3",
  "webSocketDebuggerUrl": "ws://127.0.0.1:9333/devtools/browser/..."
}

Suspected root cause

The current autoConnect path still appears to rely on default-profile DevToolsActivePort lookup.

Installed build:

• ~/.npm/_npx/.../node_modules/chrome-devtools-mcp/build/src/third_party/index.js

Relevant logic:

const userDataDir = resolveDefaultUserDataDir(...);
const portPath = join(userDataDir, 'DevToolsActivePort');
const fileContent = await fs.promises.readFile(portPath, 'ascii');
...
throw new Error(`Could not find DevToolsActivePort for ${options.channel} at ${portPath}`)

That seems incompatible with Chrome's post-136 restriction on default-profile remote debugging.

Expected behavior

For default-profile live attach on Chrome 136+:

• --autoConnect should use Chrome's current permission-based live-session attach flow, or
• fail with an explicit message that default-profile attach is no longer compatible with the old DevToolsActivePort discovery strategy

Actual behavior

--autoConnect still fails through the old default-profile discovery path even when:

• Chrome is installed
• Chrome is running locally
• remote debugging has been enabled in chrome://inspect/#remote-debugging
• a non-default userDataDir can expose a valid DevTools endpoint immediately on the same machine

Suggested directions

1. Update autoConnect to use Chrome's newer live-session attach mechanism instead of default-profile DevToolsActivePort lookup.
2. Detect Chrome 136+ default-profile restrictions and emit a specific error.
3. Document that current autoConnect is not compatible with the default Chrome profile on hardened Chrome builds unless a non-default userDataDir is used.