MCP times out when browser has MetaMask extension

[edxeth]

Description of the bug

All tools consistently time out (MCP error -32001) when connected to a Google Chrome/Chromium instance that has MetaMask. The issue does NOT occur when MetaMask is disabled or removed.

Debug logs with DEBUG=* show that all CDP protocol operations complete successfully, including:

• Target discovery via Target.setDiscoverTargets
• Auto-attaching to all targets (including extension targets)
• Running Runtime.runIfWaitingForDebugger on all sessions
• Detaching from all non-page targets

However, after the last successful CDP response ({"id":31,"result":{}}), the logs go completely silent and the tool hangs until the 60-second timeout, suggesting the issue is in the JavaScript code that processes the target list, not in CDP communication itself.

Note: Raw CDP WebSocket connections work perfectly with MetaMask enabled, and @playwright/mcp also works without issues in the same environment, indicating this is specific to how chrome-devtools-mcp processes certain target types.

Reproduction

1. Install MetaMask extension (v13.6.0 or later) in Google Chrome/Chromium
2. Launch Google Chrome/Chromium with remote debugging:

& "C:\Users\mysol\AppData\Local\Chromium\Application\chrome.exe" --remote-debugging-port=9222 --user-data-dir="$env:LOCALAPPDATA\Chromium\Automation\Web3"

3. Configure chrome-devtools-mcp with:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--browserUrl", "http://localhost:9222",
        "--logFile", "/tmp/chrome-devtools-mcp.log"
      ],
      "env": {
        "DEBUG": "*"
      }
    }
  }
}

4. Connect MCP client and call list_pages tool
5. Observe timeout after n seconds

Expectation

I expect the MCP to work even if MetaMask extension is installed or else how am I gonna inspect and debug my MetaMask integration? I know chrome-devtools-mcp cannot communicate with MetaMask due to LavaMoat but that should not stop me from performing actions on MetaMask manually and then asking the LLM agent observe the console logs and network tab with chrome-devtools-mcp for instance.

MCP configuration

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--browserUrl", "http://localhost:9222",
        "--logFile", "/tmp/chrome-devtools-mcp.log"
      ],
      "env": {
        "DEBUG": "*"
      }
    }
  }
}

Timeout settings tested:

• Request Timeout: 10000ms
• Maximum Total Timeout: 60000ms

Chrome DevTools MCP version

0.9.0

Chrome version

141.0.7390.122 (Official Build, ungoogled-chromium) (32-bit)
142.0.7444.60 (Official Build, google chrome) (64-bit)

Coding agent version

Codex CLI v0.53.0

Model version

GPT-5-Codex

Chat log

No response

Node version

v24.8.0

Operating system

Windows Subsystem for Linux (WSL)

Extra checklist

• I want to provide a PR to fix this bug

[edxeth]

I've just reproduced the issue with Google Chrome Version 142.0.7444.60 (Official Build) (64-bit) and the result is not related to Chromium, FYI.

[OrKoN]

Thanks for reporting.

However, after the last successful CDP response ({"id":31,"result":{}}), the logs go completely silent and the tool hangs until the 60-second timeout, suggesting the issue is in the JavaScript code that processes the target list, not in CDP communication itself.

I think a common reason for this is slightly different: we rely on the CDP's auto-attach mechanism and wait for all existing targets to be auto-attached when establishing a connection but it looks like CDP does not auto-attach some of the extension targets. I will try to reproduce.

[edxeth]

Hey @OrKoN — I’ve posted a fix in PR #519.

We now skip waiting for MetaMask’s extension targets during bootstrap by using filtered Target.setAutoAttach plus a short “first page or timeout” race. That keeps startup under ~2s even with service workers, offscreen docs, and background pages, while users can opt back in via --includeExtensionTargets. The fix also filters extension/devtools URLs out of list_pages by default and adds CLI flags & logging so folks can tune the behavior.

Happy to iterate if you spot anything else!

[OrKoN]

Thanks for the PR but we opted for solving this in Puppeteer via puppeteer/puppeteer#14395 Could you please give it a try in the latest version 0.10.0?

[edxeth]

Hey @OrKoN thanks for the update, I've just tried out the latest version 0.10.0, and it's working like a charm, good job!