multiple MCP processes on same debug port cause Network.enable timeout

[yuvrajangadsingh]

Problem

When MCP clients reconnect (e.g. running /mcp in Claude Code, or restarting the client), each reconnect spawns a new chrome-devtools-mcp process without killing the previous one. Multiple CDP clients on the same debug port fight over protocol sessions, causing Network.enable timed out errors.

Root cause

There's no mechanism to prevent or clean up duplicate connections to the same browser endpoint. Running lsof -i :9222 after a few reconnects shows 3-4 node processes all connected to port 9222.

The existing in-process guard in browser.ts (if (browser?.connected)) only prevents reconnections within the same process. It does nothing for separate processes.

Reproduction

1. Configure chrome-devtools-mcp with --browserUrl=http://127.0.0.1:9222
2. Start an MCP session (connect from Claude Code, Gemini CLI, etc.)
3. Reconnect the MCP session (e.g. /mcp in Claude Code)
4. Repeat 2-3 times
5. Run lsof -i :9222 | grep node and observe multiple processes
6. Any tool call now fails with Network.enable timed out

Fix

Draft PR: #1761

Adds endpoint-based PID lock files. On startup, the server checks if another instance is already connected to the same endpoint, kills it, waits for it to die, then acquires the lock.

Related: #1156, #657

[OrKoN]

Generally, Puppeteer and Chrome DevTools MCP supports multiple concurrent connections to the same browser instance. Are you sure network.enable timed out is not caused by unloaded/frozen tabs in the browser instead?

[yuvrajangadsingh]

you might be right about frozen tabs being the primary cause. i have 100+ tabs open in Arc, many of them are likely frozen/suspended. that would explain the timeout on Network.enable.

i did observe multiple chrome-devtools-mcp processes connected to the same port (4-5 at once after several /mcp reconnects), and killing the stale ones was necessary to even get a clean connection attempt. but the timeout persisted even with a single process, so frozen tabs could be the underlying issue.

is there a way to skip frozen/unloaded tabs during page enumeration? or a flag to increase the protocolTimeout for the initial connection?

marking the draft PR as what it is -- it fixes the stale process accumulation but may not fix the timeout itself.

[yuvrajangadsingh]

did some debugging. here's what i found.

setup: Arc browser, 27 page targets on port 9222.

test: connected raw WebSocket to each page target individually and sent Network.enable with a 3s timeout.

results: 18 tabs responded OK, 9 tabs timed out:

• LinkedIn Feed
• YouTube (2 videos)
• Dev.to article
• Apple MobileMe (web archive)
• Wikipedia
• Netflix
• Peerlist
• GitHub repo page

these are tabs Arc has frozen/suspended. Target.getTargets shows all of them as subtype: none, attached: true, so there's no CDP-visible way to tell them apart from active tabs before trying to send a protocol command.

when chrome-devtools-mcp tries to init all pages (Network.enable, Audits.enable, etc.), the frozen ones hang for the full protocol timeout. 9 frozen tabs x 5s timeout = 45s, which exceeds the MCP init window.

possible fix: make the per-page init calls (Network.enable, etc.) race against a short timeout (1-2s), and skip tabs that don't respond. they can be initialized lazily when the user actually selects them.

[yuvrajangadsingh]

dug deeper into the Chromium internals to understand why this happens.

why Network.enable hangs on discarded tabs

it's not "frozen" tabs, it's "discarded" tabs. Arc aggressively unloads inactive tabs to save memory. when a tab is discarded, the renderer process is gone. Network.enable calls NetworkHandler::Enable() which returns Response::FallThrough(), queuing the command for the renderer-side DevTools agent. but RenderFrameDevToolsAgentHost::EnsureAgent() fails because there's no live frame_host_. the command sits pending indefinitely until the tab is reloaded.

no CDP way to detect this beforehand

Target.getTargetInfo doesn't expose lifecycle state. Page.getFrameTree only returns frame structure. Page.setWebLifecycleState is a setter, not a getter. there's no preflight to check if a target is discarded.

suggested fix (two parts)

1. filter targets to page type only by default. the current targetFilter in browser.ts only checks URL prefixes, so iframes, workers, service_workers all pass through. in my case that's 92 targets instead of 27 pages. adding target.type() !== 'page' ? false : ... to the filter would help.

2. lazy init instead of eager init. don't call Network.enable / Audits.enable on every page at startup. init only when the user actually selects a page via select_page or list_pages. for the initial page list, just use the HTTP /json/list endpoint which doesn't need any protocol session.

the reliable pattern for interacting with a potentially discarded tab:

• call Target.activateTarget first to wake it
• then Network.enable with a short per-target timeout (1-2s)
• if still times out, mark as unloaded and skip. retry on demand.

note: Chromium's built-in freeze/discard protection only checks for an open DevTools UI window on the tab, not for remote CDP clients. so chrome-devtools-mcp connecting doesn't prevent Arc from unloading tabs.

[OrKoN]

This should have fixed it in Chromium https://chromium-review.git.corp.google.com/c/chromium/src/+/7557410 Note we do not support Arc as we do not know when and how often it gets updated and if it is modified in any way.

[OrKoN]

call Target.activateTarget first to wake it

this is not suitable because it would focus the targets on connection interrupting other tasks and we try to avoid that.