AshfaqandNatasha Gorshunova
ae0aaef884
## Problem `--blockedUrlPattern`/`--allowedUrlPattern` accept any URLPattern string, including hostnames that use a regexp group (for example `*://(127\.\d+\.\d+\.\d+):*/*`, meant to cover a whole IP range). That pattern is enforced correctly by the target-attach check (`TargetManager#isUrlAllowed`, using the real `URLPattern.test()`), but the actual network-level blocking runs through the CDP command `Network.emulateNetworkConditionsByRule`, passing the raw pattern string as `NetworkConditions.urlPattern`. That command's native matching does not apply the pattern consistently on redirects, so a page allowed to load can redirect straight through a blocked host range while an exact-hostname pattern stays blocked in both cases. Root-caused and written up in more detail on #2777. This isn't something fixable from this repo's side (the mismatch is between the documented CDP `urlPattern` semantics and the underlying Chromium implementation for `emulateNetworkConditionsByRule`, not in `puppeteer-core` or `chrome-devtools-mcp`), so instead of leaving the gap silent, this rejects patterns this repo can't currently guarantee are enforced. ## Fix - Added `findUnenforceableHostnamePattern` (`src/utils/url.ts`), which parses each pattern with `URLPattern` and flags one whose canonicalized `hostname` contains a regexp group (`(`). Wildcard (`*`) and named-group (`:name`) hostnames are unaffected and continue to work as before; a regexp group outside the hostname (e.g. in the pathname) is also left alone, since only the hostname case is demonstrated as broken. - Wired it into the `blockedUrlPattern`/`allowedUrlPattern` CLI option `coerce`, so an offending pattern fails fast at startup with a clear error instead of silently only half-working. - Updated both options' `describe` text and regenerated `docs/configuration.md` via `npm run gen`. ## Testing - Added unit tests in `tests/utils/url.test.ts` covering: a hostname regexp group (flagged), multiple patterns (first offender returned), an exact hostname, a wildcard hostname, a named-group hostname, a regexp group outside the hostname, and a pattern that fails to construct. - `npx tsc` and `npx eslint` both pass clean on the changed files. - Verified the new function's behavior against Puppeteer's own vendored `URLPattern` polyfill (`node_modules/puppeteer-core/lib/third_party/urlpattern-polyfill`), matching every case in the new test suite - my local Node (22.22) predates Node's global `URLPattern` support that this repo's `.nvmrc` (v24) assumes, so I couldn't run the built test file directly against the global here, but the polyfill is the same spec implementation and gave identical results for all cases. Fixes #2777 --------- Co-authored-by: Natasha Gorshunova <47688881+nattallius@users.noreply.github.com>
Chrome DevTools for agents
Chrome DevTools for agents (chrome-devtools-mcp) lets your coding agent (such as Antigravity, Claude, Cursor or Copilot)
control and inspect a live Chrome browser. It acts as a Model-Context-Protocol
(MCP) server, giving your AI coding assistant access to the full power of
Chrome DevTools for reliable automation, in-depth debugging, and performance analysis.
A CLI is also provided for use without MCP.
Tool reference | Changelog | Contributing | Troubleshooting | Design Principles
Key features
- Get performance insights: Uses Chrome DevTools to record traces and extract actionable performance insights.
- Advanced browser debugging: Analyze network requests, take screenshots and check browser console messages (with source-mapped stack traces).
- Reliable automation. Uses puppeteer to automate actions in Chrome and automatically wait for action results.
Disclaimers
chrome-devtools-mcp exposes content of the browser instance to the MCP clients
allowing them to inspect, debug, and modify any data in the browser or DevTools.
Avoid sharing sensitive or personal information that you don't want to share with
MCP clients.
chrome-devtools-mcp officially supports Google Chrome and Chrome for Testing only.
Other Chromium-based browsers may work, but this is not guaranteed, and you may encounter unexpected behavior. Use at your own discretion.
We are committed to providing fixes and support for the latest version of Extended Stable Chrome.
Performance tools may send trace URLs to the Google CrUX API to fetch real-user
experience data. This helps provide a holistic performance picture by
presenting field data alongside lab data. This data is collected by the Chrome
User Experience Report (CrUX). To disable
this, run with the --no-performance-crux flag.
Usage statistics
Google collects usage statistics (such as tool invocation success rates, latency, and environment information) to improve the reliability and performance of Chrome DevTools MCP.
Data collection is enabled by default. You can opt-out by passing the --no-usage-statistics flag when starting the server:
"args": ["-y", "chrome-devtools-mcp@latest", "--no-usage-statistics"]
Google handles this data in accordance with the Google Privacy Policy.
Google's collection of usage statistics for Chrome DevTools MCP is independent from the Chrome browser's usage statistics. Opting out of Chrome metrics does not automatically opt you out of this tool, and vice-versa.
Collection is disabled if CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS or CI env variables are set.
Update checks
By default, the server periodically checks the npm registry for updates and logs a notification when a newer version is available.
You can disable these update checks by setting the CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS environment variable.
Requirements
Getting started
Add the following config to your MCP client:
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest"]
}
}
}
Note
Using
chrome-devtools-mcp@latestensures that your MCP client will always use the latest version of the Chrome DevTools MCP server.
If you are interested in doing only basic browser tasks, use the --slim mode:
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest", "--slim", "--headless"]
}
}
}
See Slim tool reference.
MCP Client configuration
For setup instructions specific to your editor or agent (e.g. Antigravity, Claude Code, Cursor, VS Code), please see our Client Configurations Guide.
Your first prompt
Enter the following prompt in your MCP Client to check if everything is working:
Check the performance of https://developers.chrome.com
Your MCP client should open the browser and record a performance trace.
Note
The MCP server will start the browser automatically once the MCP client uses a tool that requires a running browser instance. Connecting to the Chrome DevTools MCP server on its own will not automatically start the browser.
Tools
If you run into any issues, checkout our troubleshooting guide. See the full Tool Reference for a complete list of all supported MCP capabilities.
Configuration
Find the complete list of server parameters (e.g., --headless, --isolated, --slim) and how to configure WebSocket connections in the Configuration Guide.
Advanced Usage
For advanced features such as handling concurrent sessions, persistent user data directories, connecting to a running Chrome instance instead of starting a new one, or debugging on Android, see our Advanced Usage Guide.
Integrating as a browser subagent
If you are developing agentic tooling and want to provide an integrated browser subagent as part of your product, we recommend building on top of Chrome DevTools for agents.
For a reference implementation, see the Gemini CLI browser agent documentation.