What Is Chrome DevTools MCP?
Chrome DevTools MCP is the official Chrome DevTools team server for connecting AI coding agents to a live Chrome browser through the Model Context Protocol. It gives the agent a DevTools-grade view of page state: screenshots, DOM snapshots, console output, network requests, performance traces, and browser debugging signals.
The page intent behind chrome-devtools-mcp npx is not broad Chrome education. The searcher wants the exact server command, a client config that works, Windows/Codex adjustments, a first verification prompt, and a clear warning about what browser data becomes visible to the connected MCP client.
How to Calculate the Correct Setup Path
Calculate the setup from four decisions: client, launch mode, browser state, and evidence target. Use the standard npx config for a clean first run, add Windows environment fields only when Codex cannot launch reliably, move to --autoConnect or --browser-url only when you intentionally want an existing Chrome session, and choose a public smoke-test URL before touching logged-in applications.
Register the server
Add the npx command to one MCP client profile. Keep it at user scope until the workflow is proven.
Restart the client
Quit the client completely so MCP discovery restarts. A partial reload often leaves stale tool state.
Run the first prompt
Ask the client to check performance on a safe public URL. Chrome should open only when a tool is used.
Confirm evidence
Look for a recorded performance trace, console or network tool access, and no sensitive tabs in scope.
Client Configs
Generic MCP JSON
Use this shape for clients that accept standard mcpServers JSON.
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest"]
}
}
}Claude Code CLI
Use user scope for a personal debugging setup before sharing a team profile.
claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latestCodex CLI
The official README documents this Codex CLI add path for the standard npx server.
codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latestWindows 11 Codex config
Use this when Codex cannot find npx or Chrome quickly enough through the default app environment.
[mcp_servers.chrome-devtools]
command = "cmd"
args = [
"/c",
"npx",
"-y",
"chrome-devtools-mcp@latest",
]
env = { SystemRoot="C:\Windows", PROGRAMFILES="C:\Program Files" }
startup_timeout_ms = 20_000VS Code MCP CLI
Use VS Code user configuration unless you intentionally want the project repository to carry the config.
code --add-mcp '{"name":"io.github.ChromeDevTools/chrome-devtools-mcp","command":"npx","args":["-y","chrome-devtools-mcp"],"env":{}}'Existing Chrome connection
Use this advanced path only with a deliberately started debugging profile on the same port.
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": [
"chrome-devtools-mcp@latest",
"--browser-url=http://127.0.0.1:9222"
]
}
}
}Debug log capture
Run this outside the client when tool discovery fails and you need a log file.
DEBUG=* npx chrome-devtools-mcp@latest --log-file=chrome-devtools-mcp.logChrome DevTools MCP vs Playwright MCP vs Browserbase
The right browser MCP depends on the job. Chrome DevTools MCP is strongest when the agent must debug one Chrome session deeply. Playwright MCP is better when the workflow needs repeatable browser journeys across engines. Browserbase fits when the team wants managed remote sessions instead of local browser state.
Chrome DevTools MCP
Best for
Live Chrome debugging, console errors, network requests, screenshots, and performance traces.
Not ideal for
Cross-browser coverage or large repeatable QA suites.
Playwright MCP
Best for
Repeatable E2E-style journeys, mobile emulation, cross-browser checks, and scripted web actions.
Not ideal for
Deep Chrome DevTools evidence from one active debugging session.
Browserbase
Best for
Managed sessions, replay, remote isolation, and cloud browser infrastructure.
Not ideal for
A lightweight local first-run debug loop.
Worked Examples
Performance audit smoke test
Register the server, restart the client, and run the performance prompt against developers.chrome.com. A successful first pass proves that Chrome launches, the trace recorder works, and the client can receive DevTools evidence.
Console and network bug triage
Ask the agent to open a local preview page, capture console errors, list failed network requests, and take a screenshot. This is where Chrome DevTools MCP is stronger than a generic text-only code review.
Existing-browser advanced session
When you need to alternate between manual testing and agent-driven checks, start Chrome with a non-default user data directory and a remote debugging port, then add --browser-url to the MCP config. Do this only when the exposed profile is intentionally safe.
Common Errors and Fixes
The client says the server is configured but Chrome never opens.
Likely cause: Chrome starts on first tool call, not merely when the server is registered.
Fix: Run the smoke prompt: Check the performance of https://developers.chrome.com.
Codex on Windows times out during MCP startup.
Likely cause: The app environment may miss shell variables, Chrome paths, or enough startup time.
Fix: Use cmd /c, SystemRoot, PROGRAMFILES, and startup_timeout_ms = 20_000 in the Codex config.
Chrome opens the wrong profile or exposes old tabs.
Likely cause: The default Chrome DevTools MCP user data directory can persist between runs.
Fix: Use a clean browser profile, --isolated, or a deliberately chosen --user-data-dir for remote debugging.
Remote debugging port connection fails.
Likely cause: Chrome was not started on the same port, or another process already owns the debugging port.
Fix: Close old Chrome debugging sessions, restart Chrome with the exact port, and match --browser-url.
The server loads but tools are missing or unclear.
Likely cause: The MCP client may not have refreshed discovery or the command may be failing silently.
Fix: Run DEBUG=* npx chrome-devtools-mcp@latest --log-file=chrome-devtools-mcp.log outside the client and inspect the log file.