Added workarounds for using chrome-devtools-mcp in WSL.
Drive-by: moved known issues from readme to troubleshooting.
Drive-by: updated skill to link to troubleshooting.
Drive-by: rephrased for clarity.
We upgrade the performance trace tools to include real-user experience
data from the Chrome User Experience Report (CrUX).
https://developer.chrome.com/docs/cruxhttps://developer.chrome.com/docs/crux/methodology
### Deets
* When a trace is stopped, the server now extracts the primary
navigation URLs from the trace (determined by insightSets).
* It calls the public CrUX API to fetch field metrics (LCP, INP, CLS)
for each unique URL/Origin.
* The formatting of crux data is handled by upstream TraceFormatter, but
it looks like this:
```md
Metrics (field / real users):
- LCP: 2595 ms (scope: url)
- LCP breakdown:
- TTFB: 1273 ms (scope: url)
- Load delay: 86 ms (scope: url)
- Load duration: 451 ms (scope: url)
- Render delay: 786 ms (scope: url)
- INP: 140 ms (scope: url)
- CLS: 0.06 (scope: url)
- The above data is from CrUX–Chrome User Experience Report. It's how the page performs for real users.
- The values shown above are the p75 measure of all real Chrome users
- The scope indicates if the data came from the entire origin, or a specific url
- Lab metrics describe how this specific page load performed, while field metrics are an aggregation of results from real-world users. Best practice is to prioritize metrics that are bad in field data. Lab metrics may be better or worse than fields metrics depending on the developer's machine, network, or the actions performed while tracing.
```
**Privacy Considerations:**
* Updates the server README to inform users that performance analysis tools may send trace URLs to the Google CrUX API.
* Adds a notification message to the server startup logs regarding the CrUX API interaction.
Doc: go/crux-in-bifrost
Fixes b/446630695
---------
Co-authored-by: Alex Rudenko <alexrudenko@chromium.org>
Co-authored-by: Alex Rudenko <OrKoN@users.noreply.github.com>
## Summary
Chrome M144 is now in the stable channel, so the note about requiring
`--channel=beta` and the example configuration using it are outdated.
## Prompt
Remove outdated documentation about --channel=beta since Chrome M144 is
now in stable channel.
## Changes
- Removed `--channel=beta` from the `--autoConnect` example
configuration
- Removed the note: "Note: you have to specify `--channel=beta` until
Chrome M144 has reached the stable channel."
## Test plan
- [x] Verified the documentation now reflects the current stable Chrome
version
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## **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:
```json
"args": ["-y", "chrome-devtools-mcp@latest", "--no-usage-statistics"]
```
Google handles this data in accordance with the [Google Privacy
Policy](https://policies.google.com/privacy).
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.
The code determining statistics that are collected is in here
https://github.com/ChromeDevTools/chrome-devtools-mcp/tree/main/src/telemetry.
Heya, Adam from @anthropics here 👋
We moved our Claude Code MCP docs, this PR updates the link. I've also
added the scope parameter given I think most users will prefer this to
be installed globally (and this matches the installation scope for other
coding assistants).
Related Issue -
https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/430
### Description
When Chrome is launched via Puppeteer, it automatically adds a set of
default flags like `--enable-automation --disable-extensions
--disable-component-extensions-with-background-pages.`
Currently, there is no way to opt out of these defaults, which makes
certain use cases difficult or impossible to support. this PR adds a way
to selectively ignore specific default Chrome launch flags applied by
Puppeteer using its
[ignoreDefaultArgs](https://pptr.dev/api/puppeteer.launchoptions#ignoredefaultargs)
property.
```json
{
"name": "chrome-devtools-mcp",
"version": "latest",
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": [
"chrome-devtools-mcp@latest",
"--ignore-default-chrome-arg='--enable-automation'",
"--ignore-default-chrome-arg='--disable-extensions'"
]
}
}
}
```
**Feedback appreciated** @OrKoN
This PR adds a new connection mode called `--auto-connect`. To activate
it, add the `--auto-connect` flag to the chrome-devtools-mcp server
configuration. With this, chrome-devtools-mcp will automatically connect
to the running Chrome instance by looking up the port and the URL in the
user data dir for the specified `--channel` (by default, `stable`).
Requires Chrome M145.
This PR adds [Qoder CLI](https://qoder.com/cli) to the MCP client
configuration section in the README.
The Qoder CLI section:
Follows the same format as other MCP clients
Is placed in alphabetical order (between Qoder and Visual Studio)
Includes a link to the Qoder CLI
[documentation](https://docs.qoder.com/cli/using-cli#mcp-servsers)
Provides the command to add the Chrome DevTools MCP server using
`qodercli mcp add`
---------
Co-authored-by: Test <shaonengtao.snt@alibaba-inc.com>
This PR adds Factory CLI to the MCP client configuration section in the
README.
The Factory CLI section:
- Follows the same format as other MCP clients
- Is placed in alphabetical order (between Cursor and Gemini CLI)
- Includes a link to the Factory documentation
- Provides the command to add the Chrome DevTools MCP server using
`droid mcp add`
This PR introduces a feature to disable some of the MCP server tool
categories to tailor it to specific use cases.
For example,
```
npx chrome-devtools-mcp@latest --no-category-emulation Disable tools in the emulation category
npx chrome-devtools-mcp@latest --no-category-performance Disable tools in the performance category
npx chrome-devtools-mcp@latest --no-category-network Disable tools in the network category
```
## Summary
Add support for connecting to Chrome via WebSocket endpoint with custom
headers, enabling authenticated remote debugging scenarios and providing
an alternative to the HTTP-based connection method.
## What's New
This PR introduces two new CLI arguments:
- **`--wsEndpoint` / `-w`**: Connect directly to Chrome using a
WebSocket URL
- Example: `ws://127.0.0.1:9222/devtools/browser/<id>`
- Alternative to `--browserUrl` (mutually exclusive)
- **`--wsHeaders`**: Pass custom headers for WebSocket connections (JSON
format)
- Example: `'{"Authorization":"Bearer token"}'`
- Only works with `--wsEndpoint`
## Use Cases
- **Authenticated remote debugging**: Use API keys, tokens, or custom
auth headers
- **Secured instances**: Connect to browser instances requiring
authentication
Michael Hablich