Headed persistent browser launch can freeze pi client during startup on macOS

[epleaner]

Summary

When chrome-devtools-mcp is used from pi as an MCP server on macOS, launching a headed browser can make the calling pi session appear frozen/unresponsive for roughly a minute while Chrome starts.

The freeze is reproducible when trying headed persistent-profile modes, and goes away when reverting to the earlier isolated configuration.

Environment

• macOS (Apple Silicon)
• chrome-devtools-mcp v0.21.0
• MCP client: pi
• Browser mode: headed

Configurations tested

Stable / no freeze on open

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "chrome-devtools-mcp",
      "args": [
        "--isolated",
        "--no-headless",
        "--logFile",
        "/tmp/chrome-devtools-mcp.log"
      ]
    }
  }
}

Configurations that caused the problem

A. Persistent profile via explicit user data dir

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "chrome-devtools-mcp",
      "args": [
        "--userDataDir",
        "/Users/<user>/.pi/chrome-devtools-profile",
        "--logFile",
        "/tmp/chrome-devtools-mcp.log"
      ]
    }
  }
}

B. Auto-connect to existing Chrome

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "chrome-devtools-mcp",
      "args": [
        "--autoConnect",
        "--channel",
        "stable",
        "--logFile",
        "/tmp/chrome-devtools-mcp.log"
      ]
    }
  }
}

C. Launched browser without --isolated

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "chrome-devtools-mcp",
      "args": [
        "--logFile",
        "/tmp/chrome-devtools-mcp.log"
      ]
    }
  }
}

Reproduction

1. Configure chrome-devtools-mcp as an MCP server in pi.
2. Use any headed, non-isolated/persistent launch configuration such as --userDataDir ... or plain no-flag persistent launch.
3. From pi, call a tool that opens a page, for example new_page https://baraza2.platform.flyzipline.com/.
4. Observe pi while Chrome is launching.

Actual behavior

• Chrome eventually opens.
• During startup, pi becomes unresponsive for roughly a minute.
• In one state, MCP calls also temporarily returned Not connected after launch attempts.
• Reverting to --isolated --no-headless restored smooth behavior.

Expected behavior

Launching a headed Chrome instance with a persistent profile should not stall or freeze the MCP client UI for an extended period.

Notes

• The main reason I tried persistent mode was to preserve Okta auth state between browser launches.
• The issue appears separate from auth itself: the freeze is about browser startup/attach behavior.
• chrome-devtools-mcp --help shows --headless defaults to false, and one direct launch log showed headless: false.
• The freeze was specifically noticeable from pi; I have not yet isolated whether the root cause is in chrome-devtools-mcp, Chrome startup with persistent profiles, or how MCP clients block while waiting for the initial browser/session handshake.

If useful, I can provide trimmed log excerpts from /tmp/chrome-devtools-mcp.log.

[epleaner]

Attaching trimmed log excerpts from /tmp/chrome-devtools-mcp.log.

A few data points from the runs:

• in the problematic runs, there was often a long gap between new_page request and the first Detecting open DevTools windows / new_page context: resolved
• examples from this session:
  • 20:24:12 → 20:24:43 (~31s)
  • 20:27:37 → 20:28:07 (~30s)
• on the reverted working config (--isolated --no-headless), the same path was much faster:
  • 20:30:31 → 20:30:36 (~5s)

2026-04-20T20:17:53.256Z mcp:log Starting Chrome DevTools MCP Server v0.21.0
2026-04-20T20:17:53.297Z mcp:log Chrome DevTools MCP Server connected
2026-04-20T20:17:53.306Z mcp:log new_page request: {
2026-04-20T20:17:58.323Z mcp:log Detecting open DevTools windows
2026-04-20T20:17:58.327Z mcp:log new_page context: resolved
2026-04-20T20:17:58.327Z mcp:log Detecting open DevTools windows
2026-04-20T20:17:58.409Z mcp:log Detecting open DevTools windows
2026-04-20T20:17:59.682Z mcp:log Detecting open DevTools windows

2026-04-20T20:24:07.930Z mcp:log Starting Chrome DevTools MCP Server v0.21.0
2026-04-20T20:24:07.969Z mcp:log Chrome DevTools MCP Server connected
2026-04-20T20:24:12.076Z mcp:log new_page request: {
2026-04-20T20:24:43.671Z mcp:log Detecting open DevTools windows
2026-04-20T20:24:43.675Z mcp:log new_page context: resolved
2026-04-20T20:24:43.675Z mcp:log Detecting open DevTools windows
2026-04-20T20:24:56.692Z mcp:log Detecting open DevTools windows
2026-04-20T20:25:01.842Z mcp:log Detecting open DevTools windows
2026-04-20T20:25:09.727Z mcp:log Detecting open DevTools windows

2026-04-20T20:27:30.291Z mcp:log Starting Chrome DevTools MCP Server v0.21.0
2026-04-20T20:27:30.335Z mcp:log Chrome DevTools MCP Server connected
2026-04-20T20:27:37.685Z mcp:log new_page request: {
2026-04-20T20:28:07.353Z mcp:log Detecting open DevTools windows
2026-04-20T20:28:07.358Z mcp:log new_page context: resolved
2026-04-20T20:28:07.358Z mcp:log Detecting open DevTools windows
2026-04-20T20:28:21.506Z mcp:log Detecting open DevTools windows
2026-04-20T20:28:27.586Z mcp:log Detecting open DevTools windows
2026-04-20T20:28:33.461Z mcp:log Detecting open DevTools windows

2026-04-20T20:30:26.197Z mcp:log Starting Chrome DevTools MCP Server v0.21.0
2026-04-20T20:30:26.265Z mcp:log Chrome DevTools MCP Server connected
2026-04-20T20:30:31.565Z mcp:log new_page request: {
2026-04-20T20:30:36.716Z mcp:log Detecting open DevTools windows
2026-04-20T20:30:36.727Z mcp:log new_page context: resolved
2026-04-20T20:30:36.727Z mcp:log Detecting open DevTools windows
2026-04-20T20:30:36.779Z mcp:log Detecting open DevTools windows
2026-04-20T20:30:38.890Z mcp:log Detecting open DevTools windows

There are also a lot of Chrome-side noise lines in the same file (google_apis/gcm, page_load_metrics, updater/crashpad permission warnings), but nothing in the MCP log itself obviously explains the long stall.

If useful, I can attach a fuller tail as well.

[m13v]

hit this same 30s stall pattern switching an agent over from isolated to persistent profile on Apple Silicon. the freeze isn't really Chrome startup, it's the profile migration/extensions/sync check that only runs when Chrome sees a real userDataDir. the MCP client blocks synchronously on the tool call the whole time because the CDP handshake doesn't complete until Chrome finishes that first-run work. two fixes that actually stuck for me: pass --remote-debugging-port and attach to an already-running Chrome instead of spawning one (the --autoConnect path but against a pre-warmed instance), or nuke the sync/extensions work with --disable-sync --disable-extensions --disable-component-extensions-with-background-pages --no-first-run on the persistent profile. the second keeps launch under 3 seconds and still preserves Okta cookies in the Default profile.