Description of the bug

In long-running coding-agent sessions using chrome-devtools-mcp@0.18.1 with --autoConnect, MCP becomes unreliable over time:

1. Tool calls fail with connection/transport errors even while Chrome remote debugging is active.
2. MCP appears to restart frequently (Starting Chrome DevTools MCP Server v0.18.1 many times in one session).
3. Reconnect churn causes repeated Chrome approval prompts ("Allow remote debugging?") because new CDP connections are created repeatedly.

This is not a one-time setup issue. Chrome was running, remote debugging was enabled, and DevToolsActivePort was valid.

Reproduction

1. Start MCP using:

args = ["-y", "chrome-devtools-mcp@latest", "--autoConnect", "--logFile", "/tmp/chrome-devtools-mcp.log", "--no-usage-statistics", "--no-performance-crux"]

2. Keep the coding-agent session running for a while and invoke MCP tools repeatedly (list_pages, new_page, etc.).
3. Observe intermittent failures and reconnect loops.

Expectation

• --autoConnect should keep a stable connection to the active Chrome instance in long-running sessions.
• If connection drops, MCP should reconnect cleanly without repeated startup churn.
• Approval UX should not be repeatedly triggered by MCP reconnect flapping.

MCP configuration

[mcp_servers.chrome-devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest", "--autoConnect", "--logFile", "/tmp/chrome-devtools-mcp.log", "--no-usage-statistics", "--no-performance-crux"]

Chrome DevTools MCP version

0.18.1

Chrome version

Google Chrome 145.0.7632.117

Coding agent version

Codex CLI (MCP client)

Model version

gpt-5.x-codex family

Chat log

N/A

Node version

v24.7.0 (npm 11.5.1)

Operating system

macOS 15.5 (24F74)

Evidence from /tmp/chrome-devtools-mcp.log

• Repeated startup entries in one session:
  • Starting Chrome DevTools MCP Server v0.18.1 (many times between 2026-03-04T03:40:46Z and 2026-03-04T06:37:38Z)
• Connection failures while Chrome debugging was on:
  • list_pages error: Error: Could not connect to Chrome...
• Incorrect fallback target in at least one attempt:
  • Connecting Puppeteer to { ..., "browserURL":"http://127.0.0.1:9223" }
• Additional noisy runtime errors:
  • Unhandled promise rejection ... ReferenceError: Node is not defined

At the same time, Chrome showed active remote debugging:

~/Library/Application Support/Google/Chrome/DevToolsActivePort:

62314
/devtools/browser/598cf21d-ec63-45f3-abba-698f26a88807

and port 62314 was listening.

Extra checklist

• I want to provide a PR to fix this bug

Suggested direction

• Persist/reuse one browser websocket in server lifecycle instead of frequent reconnect/open-close churn.
• Add explicit reconnect state machine with backoff and health checks.
• Prefer DevToolsActivePort endpoint when available over static/default browserURL assumptions.