Why do stacked 'Allow remote debugging?' popups appear with chrome-devtools-mcp --auto-connect?
When I use chrome-devtools-mcp 0.21.0 with --auto-connect to drive a live Chrome 144 browser (macOS, Node 25), multiple 'Allow remote debugging?' dialogs can stack up, and I have to click Allow/Deny several times to clear them. Why does one CDP connection trigger multiple prompts, and is there a workaround for agent tools that poll or reconnect to :9222?
Originally asked on GitHub: https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/1794
5 answers
Status: this issue is closed as not planned. The popup is intentional Chrome behavior — every new WebSocket CDP connection must be confirmed once, so parallel clients or reconnect loops naturally create stacked prompts. The MCP server cannot suppress it; prompt UI changes would need to go to issues.chromium.org.
The workaround that worked in the thread: keep one persistent WebSocket alive and route all clients through it. A local daemon that connects once and shares the socket triggers the prompt only a single time; afterwards commands run without dialogs. A contributor raised that this weakens Chrome's security boundary, since any process that can reach the daemon gets debugging access without a fresh confirmation.
Alternative architectures mentioned: a Chrome MV3 extension plus native-messaging host (e.g. Chrome Relay or chrome-cdp-extension-bridge) avoids remote-debugging-port entirely and has no per-connection prompt; this only fits interactive local workflows, not headless or sandboxed agents. Another stopgap is an auto-clicker (Yes, Dev) that watches for and approves the dialog on Windows/macOS; measured on Chrome 151, four parallel attaches went from ~35s of waiting to 2.4–4.4s unattended.
Security note: the prompt is a deliberate consent boundary for exposing :9222. Reusing a shared socket or auto-approving dialogs lets any local process attach without asking, so only do this on a trusted machine.
If you only need automation against a throwaway profile, launching Chrome with its own --user-data-dir avoids the prompt entirely.
Did this work for you?What @Eschamali tried on GitHub (Worked)
A commenter proposed and demonstrated a persistent local daemon that holds a single WebSocket connection to Chrome and routes all client requests through it; the confirmation dialog only appeared once and subsequent commands ran without prompts.
Did this work for you?What @kiluazen tried on GitHub (Worked)
A commenter described an alternative architecture using a Chrome MV3 extension plus native-messaging host (Chrome Relay) so the agent talks to the extension instead of --remote-debugging-port; no per-connection prompt appears and reconnects are silent.
Did this work for you?What @dev-newb tried on GitHub (Worked)
A commenter built Yes, Dev, a tray/menu-bar tool that watches for the 'Allow remote debugging?' dialog and auto-clicks Allow; on Chrome 151 it reduced four parallel attaches from ~35s of waiting on a human to 2.4–4.4s unattended.
Did this work for you?What a GitHub user tried on GitHub (Didn't work)
The reporter used chrome-devtools-mcp 0.21.0 with --auto-connect on Chrome 144/macOS; polling attempts and parallel subprocess connections each triggered their own popup, so users had to approve or deny several stacked dialogs.
Source: https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/1794 (opens external site)
Did this work for you?
Related questions
- Why does chrome-devtools-mcp snapshot miss table/ARIA semantics?
- Why is --load-extension ignored by chrome-devtools-mcp?
- How do I use chrome-devtools-mcp from WSL when Chrome is installed on Windows?
- chrome-devtools-mcp --autoConnect times out on every tool call with Chrome 144
- How to select which Chrome profile chrome-devtools-mcp automates when several are open?