Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/chrome-devtools-mcp/issues.md or /mcp/chrome-devtools-mcp/issues.json, or Pod over MCP.

Reported issues for Chrome DevTools MCP

Pod holds 24 of 408 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to Chrome DevTools MCP.

Most discussed

Support isolatedContext page-scoped tool routing for multi-agent workflows

Problem

PR #991 adds isolatedContext to new_page, enabling agents to create pages with isolated cookies, storage, and sessions. However, all subsequent tools (take_screenshot, take_snapshot, navigate_page, evaluate_script, emulate, click, fill, press_key, etc.) resolve their target page via the global getSelectedPage(). This means agents must call select_page before each operation, which introduces a race condition in multi-agent workflows.

The internal mutex seriali

Read the thread · 2026-02-23 · closed · outside contributor · 23 comments

Accessibility tree/element(s) snapshot - exposing semantics, roles, states, ARIA,...

Is your feature request related to a problem? Please describe. I miss more functionality to extract accessibility information from DevTools with MCP. One basic thing that would be a great start is perhaps an snapshot of the accessibility tree (probably as an extension to the "text-only" snapshot or similar.

Describe the solution you'd like Add a feature for accessibility tree snapshot of the whole page or of a single selector (CSS, XPATH) or a group of selectors (CSS, XPATH) - so that I

Read the thread · 2025-10-13 · closed · external user · 23 comments

A tool to "Select an element in the page to inspect it"

Is your feature request related to a problem? Please describe.

Select an element in the page to inspect it could arguably be the most used Chrome Dev Tools "tool".

This allows the (human) programmer to focus on just that part of the DOM he is interested in. On the other hand, most tools we put in the hands of AI agents today always give back the full DOM. The AI is then forced to first filter out all the irrelevant parts leading to the context window filling up extremely fast, and the ag

Read the thread · 2025-10-04 · open · external user · 26 comments

Cannot connect to the Chrome-devtools mcp server using the claude code

Describe the bug claude code showed it's failed to reconnect to chrome-devtools when I reconnect it.

Image

To Reproduce

  1. exec command: claude mcp add chrome-devtools npx chrome-devtools-mcp@latest
  2. exec command: claude code
  3. found 1 mcp failed

<img width="1034" height="94" alt="Image" src="https://github.com/user-attachments/assets/9eeb7289-7809-4319-967

Read the thread · 2025-09-27 · closed · external user · 31 comments

Problem to locate chrome.exe on windows 64 bits.

Describe the bug I'm trying to use chrome-devtools MCP with Cursor on windows 10 64 bits. I spent my full day trying to make it work, but I failed. The problem is that it never finds chrome.exe, even when I use --executablePath option.

To Reproduce Use cursor and windows 64 bits. Add the MCP server using mcp.json like this :

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--",
        "--executablePa

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/148) · 2025-09-25 · closed · external user · 35 comments

### Automatic connection to existing Chrome session

**Is your feature request related to a problem? Please describe.**
As a user, I want to be able to connect to an existing Chrome session in an opened browser with zero configuration work.

**Describe the solution you'd like**
I would like to issue a command to the agent, such as `navigate to http://localhost` and the tooling would take over the open session. A security confirmation prompt is of course necessary.

**Describe alternatives you've considered**
This already works quite well with Play

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/140) · 2025-09-25 · closed · external user · 29 comments

### Access chrome while in WSL environment

**Is your feature request related to a problem? Please describe.**

Codex works far better in a linux based environment thus it's generally recommended if yo are on windows to use WSL. The problem here is this MCP only tries to look for chrome inside the WSL instead of the host system.

**Describe the solution you'd like**

The MCP server would know it's in WSL and use the host system's chrome

**Describe alternatives you've considered**

Can use codex for windows but it's not officially support

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/131) · 2025-09-25 · closed · external user · 55 comments

### cursor: no tools, prompts or resources.

Installed the mcp server thorugh cursor install mcp button and is not able to connect to it. 

How to debug this? All other mcp server works and im currently running on node 22.19.0

<img width="408" height="135" alt="Image" src="https://github.com/user-attachments/assets/eb4e5cc5-32d1-45c8-b4eb-93ab7ecab41b" />

<img width="750" height="469" alt="Image" src="https://github.com/user-attachments/assets/4dea25c5-9515-4aa6-aee9-98dc106f06a5" />

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/111) · 2025-09-24 · closed · external user · 25 comments

## Most recent

### Isolated/temp-profile Chrome survives MCP death on macOS (puppeteer_dev_chrome_profile orphans, ppid=1)

## Summary

On macOS, Chrome instances launched by `chrome-devtools-mcp` via Puppeteer's **temporary profile** (`puppeteer_dev_chrome_profile-*`) keep running after the MCP server process is gone. They reparent to `launchd` (`ppid=1`) and accumulate for hours.

This is **not** "please add a close-browser MCP tool" (#484) and **not** "idle page CPU in connected mode" (#2599). It is also distinct from #1765, where SIGTERM of a still-alive MCP server *does* clean up Chrome. The hole is: **MCP dies 

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2621) · 2026-08-26 · open · external user · 1 comment

### Question: optional release-evidence gate for MCP artifact workflows

Hi maintainers — I’m maintaining a small, independent downstream consumer for the experimental MCP Registry #1404 receipt shape: https://github.com/yandexuanxuan/mcp-evidence-gate

Would you be open to trying one optional `workflow_dispatch` job on a fork or branch that verifies a release artifact with this immutable Action reference?

    yandexuanxuan/mcp-evidence-gate@7b1569284e321976b4b61378c223ce6a28fbdb9b (v0.1.0-alpha.1)

The Action does not scan source, install packages in the consumer r

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2616) · 2026-08-26 · closed · external user · 1 comment

### docs(security): add a HOL Guard client-side tool-call protection example

### Context

`SECURITY.md` correctly puts validation of inputs, including tool calls and parameters, on the calling agent/client, and recommends client-side precautions against prompt injection. There is currently no concrete example showing users how to put a pre-tool security gate in front of `chrome-devtools-mcp`.

### Proposal

Would you be open to a small optional documentation addition, ideally in `SECURITY.md` or the security-facing usage docs, for **HOL Guard** as a client-side protectio

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2611) · 2026-08-24 · closed · external user · 1 comment

### Long-lived server can retain active page indefinitely and keep consuming CPU after client activity stops

### Summary

On a long-lived self-hosted `chrome-devtools-mcp` 1.7.0 deployment, a page left open after an agent finishes can continue consuming substantial CPU indefinitely even though there are no MCP tool calls in flight.

This appears distinct from the 1.6.0 memory/source-map issues in #2431 / #2456, which are marked fixed in 1.7.0. The problem here is lifecycle: an active page remains live forever unless the client explicitly navigates it away/closes it or the server/browser process is recy

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2599) · 2026-08-20 · open · external user · 3 comments

### Logpoints: log runtime values without modifying source code

### Is your feature request related to a problem? Please describe.

When an agent needs to know what a page actually *does* at runtime — which branch
ran, what a value held, in what order events fired — its only real option today is to
edit the source, add `console.log`, rebuild, reload, read the output, and then remove
the calls again. That has four costs:

1. It's a **write to the user's codebase to answer a read-only question**, and stray
   `console.log` calls get left behind and committed.

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2584) · 2026-08-17 · open · external user · 1 comment

### Lighthouse secondary fetches can cross --allowed-url-pattern after redirects

### Description of the bug

In `chrome-devtools-mcp@1.7.0`, Lighthouse secondary fetches for
`/robots.txt` and `/llms.txt` can follow an HTTP redirect from an allowed
origin to an origin excluded by `--allowed-url-pattern`.

The direct control behaves as expected: a normal subresource request from the
audited page to the excluded origin is blocked and the excluded server receives
no request. During `lighthouse_audit`, however, the same excluded server
receives the redirected `/robots.txt` and `/

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2567) · 2026-08-12 · closed · external user · 8 comments

### Large Audits backlog starves all page-facing tool calls

### 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:

```text
No handler registered for issue code PerformanceIssue

This looks like a regression or broader consequence of #1850 / #1852

Read the thread · 2026-08-11 · closed · external user · 9 comments

Add option to automatically skip JavaScript debugger pauses

Is your feature request related to a problem? Please describe.

When using chrome-devtools-mcp for browser automation, some pages contain debugger; statements or anti-debugging scripts.

Once the MCP server connects through Chrome DevTools Protocol (CDP), these debugger statements cause JavaScript execution to pause, making the page appear frozen. This affects automation workflows because actions such as clicking, evaluating scripts, and navigation may become unreliable.

Currently, users

Read the thread · 2026-08-11 · closed · external user · 2 comments

Feature Suggestion: Optional token metering & paid API key support via neuforge-pay

Hi @ChromeDevTools,

Love the work on ChromeDevTools/chrome-devtools-mcp! As usage grows across AI agent frameworks, server compute costs can start adding up quickly.

Would you be open to adding an optional usage metering & billing decorator using neuforge-pay? It allows developers hosting instance deployments of your MCP server to automatically meter tokens, track real-time LLM COGS, and attach paid Stripe keys in 3 lines of code.

Example Integration:

from neuforge_pay import me

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2537) · 2026-08-11 · closed · external user · 1 comment

### `--screenshotMaxWidth` returns images at twice the bound on a HiDPI display

### Description of the bug

`--screenshotMaxWidth` caps the image before the device scale factor is applied, so on a 2x display the returned screenshot is twice the requested width. Asking for 800 gives back 1600, four times the area.

That matters most where the flag came from: #1823 added it to keep screenshots under the 8000 pixel limit behind #879, and a cap picked to stay under that would still exceed it by the same factor.

The overshoot is also what gets billed. Anthropic prices an image 

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2531) · 2026-08-10 · closed · outside contributor · 4 comments

### Unknown CLI flags are silently ignored, so a typo'd `--browserUrl` launches a browser instead of connecting

### Description of the bug

The MCP server accepts unrecognized CLI flags without an error or a warning, so a single character typo in `--browserUrl` is silent and the server falls back to launching its own browser. The agent then works against an empty browser while its configuration says it is attached to an existing one.

The CLI's `start` command launches the same server under `.strict()`, with `--browserUrl` as its own documented example, so the two entry points disagree about the same flag

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2530) · 2026-08-10 · closed · outside contributor · 2 comments

### URL allow/block policy not re-validated after HTTP redirect in loadResource

### Description of the bug

The URL allowlist/blocklist policy is only validated against the initial navigation target. If an allowed origin responds with an HTTP redirect (e.g. a 302), the browser follows it to the final destination without re-checking that destination against the configured policy.

This means a URL that passes the allow/block check can still cause navigation to a URL that the policy was specifically configured to block, as long as an attacker can influence a redirect response

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2502) · 2026-08-08 · closed · external user · 2 comments

### `performance_start_trace` silently truncates traces by enabling `invalidationTracking`

### Description of the bug

`performance_start_trace` always enables `disabled-by-default-devtools.timeline.invalidationTracking`. On a page that invalidates style heavily, that category fills the trace buffer within a few hundred milliseconds, so the recording stops long before the interaction being measured finishes. Nothing reports this: the tool returns a normal result and the trace parses fine, it just no longer contains the work you were looking at.

The category list carries this comment:

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2499) · 2026-08-07 · closed · outside contributor · 3 comments

### [Security] DevTools source-map requests bypass --blocked-url-pattern & defense-in-depth gaps

### Description of the bug

During a security review (previously reported to Google VRP, who suggested opening a public issue here), I identified a security control bypass in DevTools resource loading, along with a few defense-in-depth gaps in the default configuration.

The core issue is that --blocked-url-pattern does not block internal network requests made by Chrome's DevTools source-map resolver, allowing an attacker-controlled webpage to bypass network restrictions and interact with localh

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2493) · 2026-08-07 · closed · external user · 1 comment

### A client that never answers roots/list blocks every tool for 60s

### Description of the bug

`getContext()` awaits `updateRoots()` whenever it builds a new `McpContext`, and `ToolHandler.handle()` has already taken the tool mutex by then. So the server blocks on a `roots/list` request to the client while holding the lock that serializes every tool call.

If the client negotiated the `roots` capability but does not answer, that request only settles when the SDK's default request timeout of 60s expires. The tool call then completes normally – it never needed th

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2476) · 2026-08-05 · closed · outside contributor · 0 comments

### Release workflow downloads `mcp-publisher` from another org's `releases/latest` unpinned, then hands that binary the OIDC publishing credential

`.github/workflows/publish-to-npm-on-tag.yml`, as on `main`.

## The shape

`id-token: write` is granted at **workflow** level, so every job inherits it:

```yaml
permissions:
  id-token: write # Required for OIDC
  contents: read

That permission is the publishing credential — the npm step uses trusted publishing and there is no token secret anywhere in the file:

npm publish --provenance --access public

The second job inherits it and declares no override:

  publish-to

[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2470) · 2026-08-05 · closed · external user · 2 comments

The remaining reports are on [the project's issue tracker](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues).