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

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.

Reproduce the freeze from pi using the headed persistent configurations in the issue, then compare them with the stable --isolated --no-headless setup. Start with /tmp/chrome-devtools-mcp.log and the chrome-devtools-mcp --help output; use the reported MCP connection state and startup duration to identify the affected handshake or launch path. Done means persistent headed launch no longer stalls pi and MCP calls remain connected.