Large Audits backlog starves all page-facing tool calls

[zjh7890]

Description of the bug

When chrome-devtools-mcp connects to a long-lived Chrome session whose page targets have accumulated a large DevTools Audits backlog, page-facing MCP tools consistently time out even though the browser-level CDP endpoint and every individual page target remain responsive.

In the affected session, the MCP process repeatedly writes:

No handler registered for issue code PerformanceIssue

This looks like a regression or broader consequence of #1850 / #1852: the warning is present again in v1.7.0, and a sufficiently large initial Audits.issueAdded replay appears to starve normal tool requests. It is also related to the eager all-tab work discussed in #1921, but reproduces with only 32 page targets rather than hundreds or thousands.

The following page-facing tools were tested and all timed out in the affected MCP session:

• list_pages
• evaluate_script
• list_network_requests

An MCP-level ping can still succeed while these tools are unavailable.

Diagnostic evidence

• Chrome exposed 32 normal page targets.
• Direct browser-level CDP Target.getTargets, Target.attachToTarget, and Runtime.evaluate succeeded for every page; each page probe completed in under one second.
• Enabling the Audits domain directly replayed 17,357 Audits.issueAdded events, mostly CookieIssue, GenericIssue, and PerformanceIssue.
• After a five-second warm-up, only five new audit events arrived during the next ten seconds. This indicates that the large burst was primarily retained history rather than continuous page traffic.
• A public trigger was verified separately on https://example.com: 500 synchronous document.cookie reads produced exactly 500 PerformanceIssue/DocumentCookie events.

No page target was crashed, discarded, or unresponsive during the direct-CDP control test.

Reproduction

Public-only reproduction shape:

1. Start Chrome with remote debugging enabled.

2. Open multiple tabs at https://example.com.

3. In each tab, run the following in DevTools Console to accumulate PerformanceIssue/DocumentCookie entries:

   for (let i = 0; i < 1000; i++) {
     void document.cookie;
   }

   Repeat across enough tabs to build an Audits backlog of roughly 15,000-20,000 events. The backlog size can be confirmed through a separate raw-CDP session by enabling Audits and counting Audits.issueAdded events.

4. Connect chrome-devtools-mcp to that Chrome instance using either --autoConnect or a browser WebSocket endpoint.

5. Call list_pages.

6. Call a page-specific tool such as evaluate_script with a trivial function.

Observed behavior:

• Tool calls do not return before the client's 60-second timeout.
• stderr repeatedly reports the unhandled PerformanceIssue warning.
• Direct CDP calls to the same browser and pages continue to complete normally.
• Restarting only the MCP process does not remove the retained Audits backlog, so reconnecting replays it again.

Expectation

A large retained Audits backlog, including unknown or unsupported issue codes, should not block unrelated MCP tool calls.

Possible safeguards include bounding/deduplicating initial issue replay, dropping unsupported issue codes before mapping/logging, and ensuring Audits processing cannot starve tool requests.

MCP configuration

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@1.7.0",
        "--autoConnect"
      ]
    }
  }
}

The same behavior was observed with an explicitly supplied loopback --wsEndpoint; the endpoint identifier is intentionally omitted.

Chrome DevTools MCP version

1.7.0

Chrome version

151.0.7922.76

Coding agent version

N/A. The failure was observed at the MCP tool-call boundary and compared against raw CDP calls.

Model version

N/A

Chat log

N/A

Node version

22.22.2

Operating system

macOS 26.5.1

Extra checklist

• I want to provide a PR to fix this bug

[OrKoN]

@nroscino could you please try to create a repro as a standalone script?

[nroscino]

sure @OrKoN! Will try to repro later during the afternoon!

[cylixlee]

I've encoutered with this issue too.

[nroscino]

Hello @cylixlee @zjh7890! I have been trying to reproduce this but cannot really make it timeout.

This is the script I am using to generate the pages with issues:

import puppeteer from "puppeteer";

async function run() {
  const browser = await puppeteer.launch({
    headless: false,
    args: ["--remote-debugging-port=9222"],
  });

  const wsEndpoint = browser.wsEndpoint();
  console.log(`\nBrowser WebSocket Endpoint: ${wsEndpoint}`);

  const NUM_TABS = 400;
  const EVENTS_PER_TAB = 1000;

  const pages = [];

  while (pages.length < NUM_TABS) {
    const page = await browser.newPage();
    await page.goto("https://example.com");
    pages.push(page);
  }

  let actualIssueCount = 0;
  const clients = [];

  console.log("Generating issues...");

  for (let i = 0; i < pages.length; i++) {
    const page = pages[i];

    const client = await page.createCDPSession();
    clients.push(client);

    client.on("Audits.issueAdded", () => {
      actualIssueCount++;
    });
    await client.send("Audits.enable");

    await page.evaluate((limit) => {
      for (let j = 0; j < limit; j++) {
        document.cookie = `test${j}=1; SameSite=None`;
      }
    }, EVENTS_PER_TAB);

    await new Promise((r) => setTimeout(r, 50));
  }

  for (const client of clients) {
    await client.detach();
  }

  console.log(`Setup complete. Verified ${actualIssueCount} Audits events were generated in the browser.`);
  console.log(
    `DEBUG=* npx @modelcontextprotocol/inspector npx -y chrome-devtools-mcp@latest --wsEndpoint=${wsEndpoint}`,
  );

  await new Promise(() => {});
}

run().catch(console.error);

@OrKoN can you also try to repro?

[OrKoN]

@nroscino it does not timeout for me but I also do not get any issues in list_console_messages do you get any?

[cylixlee]

I was using DeepSeek Harness (WebUI) and I told it to open YouTube using the Chrome DevTools MCP. Chrome did open the website but the stderr is full of No handler registered for issue code PerformanceIssue.

Here's my reproduce: https://github.com/cylixlee/chrome-devtools-mcp-reproduce

[OrKoN]

I believe any messages in stderr should not have any effect on functionality. Stderr can be used for logging according to the MCP spec. Also, #2535 might have fixed it.

[nroscino]

@nroscino it does not timeout for me but I also do not get any issues in list_console_messages do you get any?

no I also don't get them even if I explicitly log something, but from the console tab in DT I can see them