Chrome DevTools MCP: How to let Claude Code drive real Chrome — 42 tools in v0.26.0, Lighthouse audits, and Sales Claw integration

"Claude Code and Cursor are smart, but they can't see inside the browser— so CSS regressions, JS errors, and Lighthouse score drops still need a human at the DevTools panel." That long-standing gripe got a design-level answer on 2025-09-23, when the Google Chrome team shipped Chrome DevTools MCP (chrome-devtools-mcp).

Chrome DevTools MCP is an official MCP server that conforms to the Model Context Protocol (MCP). It lets major AI coding agents — Claude Code, Codex, Cursor, Gemini CLI, Cline — drive a real, locally running Chrome instance. As of v0.26.0 (released 2026-05-12), it exposes 42 tools across 10 categories: Lighthouse audits, Core Web Vitals measurement, network monitoring, memory snapshots, and Chrome extension debugging are all first-class "fingertips" for the agent.

Primary sources for this article are the ChromeDevTools/chrome-devtools-mcp GitHub repo, the npm package, the Chrome for Developers Blog, and the CHANGELOG for each release tag. Version numbers, release dates, tool counts, and client names all follow the official spellings.

1. What Chrome DevTools MCP is — the official answer to "let the AI see the screen"

Until now AI coding had a fundamental gap. The LLM could read and write code, but it could not see what was happening inside the browser. Whether CSS was broken, whether Largest Contentful Paint had regressed, whether a request was returning 404 — those were tasks a human did with DevTools open.

Chrome DevTools MCP collapses that boundary into a clean four-layer pipeline: "AI agent ↔ MCP server ↔ Puppeteer ↔ real Chrome." From the AI's perspective, Chrome is just another MCP server alongside an image generator or filesystem server. When Claude Code or Cursor calls a tool like take_screenshot or lighthouse_audit, a real Chrome boots and runs in the background.

Crucially, Chrome DevTools MCP does not invent its own protocol. It conforms to the Anthropic-led Model Context Protocol (MCP), the same interface that Claude Code, Cursor, Codex, Gemini CLI, and Cline already speak. In the Host / Client / Server three-tier model this is the Server tier.

2. What changed from v0.22 to v0.26 (per the official release notes)

chrome-devtools-mcp ships at near-weekly cadence. Pulling the diff for the last five releases from GitHub Releases as a primary source:

Two of these are particularly hard to overlook: v0.24.0's "in-Lighthouse agent browsing" and v0.26.0's --autoConnect. The former lets the AI read the Lighthouse audit results page directly through tools. The latter lets you toggle "attach to an existing Chrome instance" mode with a single CLI flag. In effect, "lend my already-authenticated Chrome to the AI" is now a one-line configuration.

3. Architecture — 42 tools × 10 categories, with Puppeteer underneath

Chrome DevTools MCP uses Puppeteer (Google's official headless Chrome library) under the hood, launching a real Chrome process (stable / canary / dev / beta) on the host OS and driving it. The AI agent makes MCP tool calls; the MCP server handles browser launch, teardown, page management, DOM snapshotting, and so on.

Categories and representative tool names (summarized from the official docs/tool-reference.md):

4. Installation — Claude Code / Codex / Cursor / Gemini CLI

Prerequisites: Node.js v20.19 or newer (current LTS) and Chrome stable or newer. The package is on npm; each client's MCP config takes a JSON entry like the one below.

Claude Code

Claude Code uses claude mcp add (see Claude Code Docs — Connect Claude Code to tools via MCP).

# Register Chrome DevTools MCP with Claude Code
claude mcp add chrome-devtools npx -- -y chrome-devtools-mcp@latest

# Attach to an existing Chrome (--autoConnect, since v0.26.0)
claude mcp add chrome-devtools npx -- -y chrome-devtools-mcp@latest --autoConnect

# Confirm it's running
claude mcp list

Codex CLI

Codex CLI reads ~/.codex/config.toml. Add an entry under [mcp_servers].

# ~/.codex/config.toml
[mcp_servers.chrome-devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest"]

Cursor / VS Code Copilot / Cline

Cursor, VS Code Copilot, and Cline all use the MCP servers configuration UI (or the equivalent ~/.cursor/mcp.json). Paste the same JSON:

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

Gemini CLI

Gemini CLI uses ~/.gemini/settings.json, with the same structure under mcpServers (see Gemini CLI Docs — MCP servers with Gemini CLI).

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--channel", "canary"]
    }
  }
}

See how Sales Claw lets the AI run pre-send inspection in a real browser.

無料・MIT ライセンス。インストールせずにライブデモも試せます。

無料でダウンロードライブデモを試すGitHub

5. Seven practical use cases — from Lighthouse to extension debugging

5-1. Automated Lighthouse audits

Tell Claude Code "run a Lighthouse audit on https://example.com and propose three improvements for any metric below 70" — the AI calls lighthouse_audit, reads the scores, and goes into your code to suggest fixes.

5-2. Continuous Core Web Vitals measurement (LCP / INP / CLS)

Four-step loop: performance_start_trace → page interaction → performance_stop_trace → performance_analyze_insight. Get a performance trace including LCP, INP, and CLS — analyzed by the AI. This is a flagship example in the Chrome for Developers Blog; you plug AI directly into the frontend optimization cycle.

5-3. Form auto-fill with pre-send screenshots

fill_form or fill populates multiple fields at once; take_screenshotcaptures the pre-send state as an image. For AI sales automation, this is exactly the audit-log shape you want — "what did we put in the form, exactly?" — with image-level fidelity.

5-4. Network request monitoring

With list_network_requests and get_network_request, the AI can examine API calls, status codes, and payloads from a page transition. "Why is the Stripe checkout session returning 400?" becomes a task the AI does the same way a human would in the DevTools Network panel.

5-5. Memory leak hunting (heap snapshots)

take_memory_snapshotcaptures a heap snapshot; the AI analyzes which Detached Nodes are growing. SPA memory-leak investigation used to be heavy DevTools work — that's another job the AI can take on now.

5-6. Chrome extension debugging

Enable the v0.22.0 feature set with --categoryExtensions. Install your own Chrome extension, fetch console messages, debug background scripts — all via the AI. Extension developer productivity goes up sharply.

5-7. Authenticated sites (lend the AI your real Chrome)

The official README is explicit: some authentication services block WebDriver-controlled browsers. The official workaround is "attach to an existing Chrome instance." v0.26.0's --autoConnect means you can keep your normal Chrome running and let the AI navigate_page to a cookie-authenticated page directly.

6. How Sales Claw integrates this — a second defense layer for pre-send inspection

Sales Claw is an OSS tool that lowers misfire and policy-violation risk through policy control, pre-send checks, do-not-contact detection, CAPTCHA-on-detect stop, rate limits, and audit logs. Adding Chrome DevTools MCP gives the pipeline a check layer that is closer to "what a human staring at real Chrome would see."

An example three-layer defense:

1. Layer 1: LLM judgment— copy generation for contact forms plus automatic detection of "do not contact" / policy-violation phrases (existing).
2. Layer 2: Lightweight Playwright submit — DOM analysis + submit, with CAPTCHA-on-detect stop (existing).
3. Layer 3: Chrome DevTools MCP pre-send inspection (new) — capture the filled form with take_screenshot, pull JS errors via list_console_messages, log the submit API status from list_network_requests into the audit log.

# Example: Claude Code → Sales Claw with Chrome DevTools MCP
> Fill this form with [generated copy]. Before pressing submit,
  run take_screenshot and list_console_messages. If there are
  any JS errors, stop the submission and queue it as awaiting_approval.

With this layer you can catch the kind of anomaly Playwright alone misses — "unknown tracking parameters were injected into hidden form fields," "the submit button doesn't render under this UA," or "the UI shows success while the API returned 500" — and write the evidence to the audit log. That's the Sales Claw-flavored additional line of defense for policy-controlled autonomous operation.

7. Risks and safe-by-design choices for policy-controlled autonomous operation

Using Chrome DevTools MCP in policy-controlled autonomous operation means actively lowering each risk through automated checks and design. We don't claim "safe" — we structurally lower risk.

7-1. Risk: AI driving a browser that holds authentication cookies

• Mitigation: keep your work browser fully separate from the AI-connected browser using --isolated. If you must use --autoConnecton a production machine, create a dedicated "Sales Claw" Google account and share only that Chrome.
• Residual: services where the AI-connected profile is logged in are reachable. Document "what the AI may operate" per service.

7-2. Risk: gaps in tool-execution permission

• Mitigation: require --permission-mode ask or acceptEdits on the Claude Code side. Forbid --dangerously-skip-permissions in production.
• Residual: fill / click-class tools have side effects. Design a confirm step that always wraps them.

7-3. Risk: concurrent sessions and resource consumption

• Mitigation: cap concurrent Chrome MCP processes per machine. Pair concurrency with Sales Claw rate limits — split work into goal-driven batches via subagents.
• Residual: memory use can balloon unpredictably. Periodically run take_memory_snapshot as a watchdog.

7-4. Risk: behavioral drift from weekly updates

• Mitigation: pin a version in production (for example chrome-devtools-mcp@0.26.0). Read the CHANGELOG weekly, validate before bumping.
• Residual: Chrome itself auto-updates and may change behavior. Record the Chrome version alongside the MCP version.

7-5. Risks that remain by construction

• Auth services with strict WebDriver detection may still block sessions (per the README).
• Site structure changes can cause fill_form to populate the wrong elements.
• Novel CAPTCHA variants may slip past detection until Sales Claw is updated.
• Third-party DevTools integration and WebMCP are experimental — do not use in production.

8. Pre-production checklist

9. Bottom line — 2026 is the year "lend the AI a real Chrome" becomes routine

Chrome DevTools MCP is Google's frontal answer to the long-running AI-coding gap of "can't see inside the browser." The path from v0.22.0 (extension debugging) to v0.24.0 (in-Lighthouse agent browsing) to v0.25.0 (third-party DevTools integration) to v0.26.0 (autoConnect) raised the AI-browser-automation baseline in just a month.

For sales automation systems like Sales Claw, this means a second defense layer for pre-send inspection becomes standardizable via MCP. LLM judgment → Playwright submit → Chrome DevTools MCP real-Chrome inspection — every layer reachable from every AI client through one MCP surface.

Next action: install chrome-devtools-mcp@latest locally with --isolated, and run lighthouse_audit on a site you care about. The first tool call covers most of what this article describes. For Sales Claw integration, also read the Quick start and MCP complete guide.

Read this, then run lighthouse_audit once.

無料・MIT ライセンス。インストールせずにライブデモも試せます。

無料でダウンロードライブデモを試すGitHub