chrome-devtools-mcp Shipped a CLI and a Skill. That Moved the Approval Gate.

Chrome's official agent tooling is now three products in one repo, and the security notice hands the hard part to the component least able to do it.

The repository is called chrome-devtools-mcp. Inside it, at skills/chrome-devtools-cli/SKILL.md, sits a file whose description reads: "Use this skill to write shell scripts or run shell commands to automate tasks in the browser or otherwise use Chrome DevTools via CLI."

Read that twice. The MCP server repo ships a skill that teaches your agent to stop using MCP.

That is not a criticism, and it is not an accident. Google folded the project into a suite it now calls Chrome DevTools for agents, which the docs describe as three things: an MCP server, a CLI, and agentic skills. It is a sensible product decision with a consequence almost nobody is talking about, which is that MCP tool calls and shell commands do not pass through the same approval machinery in most harnesses.

Why the surface matters more than the tools

Every capability I am about to list existed before this. Puppeteer has driven Chrome for years. The Chrome DevTools Protocol has always been able to read every network request on a page.

What changed is who is holding the wheel, and what sits between the wheel and the road.

When your agent calls an MCP tool, the harness sees a named tool with typed parameters. It can allow take_screenshot and deny evaluate_script. That granularity is the entire value proposition of tool-level permissioning.

When your agent runs chrome-devtools evaluate_script "() => document.cookie", the harness sees a bash command. In Claude Code, which as of today defaults to auto mode, bash goes to a classifier that decides whether the command looks destructive. A classifier is a good control. It is a different control, and it is evaluating a string rather than a schema.

I am not saying Chrome did this to route around permissions. I am saying the CLI is genuinely more ergonomic for scripted work, which is exactly why people will use it, which is why the approval surface will move whether or not anyone planned it.

What is actually in the box

The repo page served 48.3k stars and 3.3k forks today, with 75 open issues and 31 open pull requests. A cached file view inside the same repository, loaded the same day, showed 43.8k and 2.8k. That 4.5k gap is worth naming rather than averaging away, because it is what checking a fast-moving repo actually looks like: two Google-served pages, one afternoon, two answers. Take the higher pair as the fresher reading and treat both as approximate.

The npm package chrome-devtools-mcp was at v1.7.0, published August 10. The project launched as a public preview on September 23, 2025, written up by Mathias Bynens and Michael Hablich.

The tool surface, taken from the CLI skill file, is wider than "debugging" suggests:

Page control. navigate_page, new_page, select_page, close_page, list_pages. New pages can be created in the background or in an isolated context.

Input automation. click, fill, hover, drag, press_key, type_text, handle_dialog, and upload_file, which pushes a file from local disk through a form on the page.

Inspection. take_snapshot returns an accessibility tree with stable uids the agent uses to target elements. list_network_requests and get_network_request read traffic, and get_network_request takes --requestFilePath and --responseFilePath to write request and response bodies to disk. list_console_messages, take_screenshot, evaluate_script, take_memory_snapshot.

Performance. performance_start_trace, performance_stop_trace, performance_analyze_insight, and lighthouse_audit in navigation or snapshot mode.

Emulation. Network conditions, CPU throttling, geolocation, color scheme, viewport, user agent.

Extensions. list_extensions, install_extension from a local path, uninstall_extension, reload_extension, trigger_extension_action.

That last group is the one I would sit with. Your coding agent can install a Chrome extension.

There are experimental tools behind flags too: click_at for coordinate clicking under --experimentalVision, screencast recording that needs ffmpeg, and list_webmcp_tools.

The CLI holds state between commands. The skill tells the agent to run tools directly because "the background server starts implicitly," and explicitly says not to run start, status, or stop first. So a sequence of shell calls behaves like one continuous session, which is convenient and also means the browser stays warm between anything the agent decides to do.

The sentence that does the most work

Chrome's own documentation is admirably direct about the risk. From the get-started page:

Chrome DevTools for agents exposes your browser content to your agent. This allows your agent to read, inspect, debug, and modify any data in the browser or DevTools. Because your agent will be able to view and interact with the pages it accesses, it can effectively act on your behalf if you connect it to a browser with an active, authenticated session.

Good warning. Specific, unhedged, tells you the actual failure mode.

Then the repository's security policy adds this, under Scope: it is "the expectation that the AI agent or client using this MCP server validates any input (including tool calls and parameters) before sending it."

I keep coming back to that line. Input validation is assigned to the agent. The agent is a language model. The failure mode the entire industry has been documenting for two years is that a language model cannot reliably separate content it reads from instructions it follows. That is the mechanism behind every prompt-injection incident in agent tooling, and it does not have a fix, only mitigations.

So the component being handed responsibility for validating input is the component that is definitionally bad at distinguishing input from instruction. And the input in question is arbitrary web pages, read by a browser holding your logged-in sessions.

Chrome is not wrong to say it. Where else would they put it? The MCP server is a transport. It cannot know whether a fill call came from your prompt or from text on the page the agent just read.

To their credit, the security policy does not stop at the warning. It ships actual knobs: --allowed-url-pattern and --blocked-url-pattern to fence which origins the browser will touch, MCP roots for scoping filesystem access, --experimentalStructuredContent for cases where output structure matters, and a plain recommendation to run the whole thing under an OS sandbox or a separate VM. It also says, without hedging, "prefer using this server with trusted web content or make sure your client takes precautions against prompt injections."

So the controls exist. They are off by default, documented in a file most people never open, and none of them are in the copy-paste config block that everybody actually uses.

Which means the safety work is yours. Do it.

Put this into practice

The setup takes about five minutes, and the only decision that matters is which browser profile you point it at.

Install it into a throwaway Chrome profile with nothing logged in. This is step one for a reason. The docs' security warning turns on the phrase "active, authenticated session." A profile with no sessions turns the worst-case outcome from account compromise into a wasted afternoon. The configuration page covers browser launch options.
Install for your agent. In Claude Code: /plugin marketplace add ChromeDevTools/chrome-devtools-mcp, then /plugin install chrome-devtools-mcp@chrome-devtools-plugins. For Gemini CLI: gemini extensions install --auto-update https://github.com/ChromeDevTools/chrome-devtools-mcp for the MCP plus skills, or gemini mcp add chrome-devtools npx chrome-devtools-mcp@latest for the server alone. For Codex: codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest. Antigravity 2.0 ships it pre-bundled as a browser sub-agent.
Run the docs' own smoke test. Prompt: Check the performance of https://developers.chrome.com. You should see a browser window open and a trace record. If it fails, the repo ships a troubleshooting skill and you can prompt the agent to use it by name.
Then run one real task worth the setup. Point it at a local page that is broken and ask "why does submitting the form fail after entering an email address?" This is where it earns its keep. An agent that can read the console, watch the network tab, and click the button is diagnosing rather than guessing.
Look at what list_network_requests returns, once, by hand. Run it yourself against a page you are logged into on a test account. Whatever you see in that output is what your agent sees on every page it visits. Most people have never actually looked.
Set --allowed-url-pattern before you point it at anything real. If the agent only needs localhost:8080 and your staging domain, say so. This is the single highest-value flag in the package and it is not in any of the quick-start configs.
Deny the extension tools if you are not using them. install_extension has no business being available to a general-purpose coding session. Whatever deny-rule mechanism your harness has, spend the two minutes.

Honest limitations

The CLI is a subset, and the docs say so. From the get-started page: "while Chrome DevTools for agents provides the full suite of tools, the CLI only supports a targeted subset for shell-based automation." If you need the whole surface, you are on MCP.

The star count is soft, as covered above. Two Google-served pages, same day, 4.5k apart. Anyone quoting a precise number for this repo, including me, is quoting a page load.

Experimental tools need explicit flags and extra dependencies. Coordinate clicking, screencasting, and WebMCP tool listing are all off by default, and screencast needs ffmpeg installed separately.

Version requirements are looser than the docs summary suggests. The prose says Node.js LTS and current stable Chrome. The package's actual engines field is ^20.19.0 || ^22.12.0 || >=23, which is broader than "latest LTS." Check the field, not the sentence.

Isolation is documented but not enforced. The README notes that Chrome requires a non-default --user-data-dir for remote debugging, so profile separation is at least on the page. Nothing in the install path makes you do it. If you paste the quick-start config into your daily driver and connect it to your everyday Chrome, it will work perfectly, and that is the problem.

The validation expectation still has no reference implementation. The security policy tells clients to validate tool calls and parameters, and gives you URL patterns and sandbox advice as partial answers. It does not show a client actually doing the input validation it asks for, and I did not find one published. If your harness has an answer here, I want to hear it.

Where that leaves you

This is the best browser tooling any agent has had, shipped by the people who built the browser, and I would use it. The performance trace analysis alone is worth the install, because a coding agent reasoning about a real LCP breakdown is doing something categorically different from a coding agent guessing at CSS.

But notice what the past week has been about. Anthropic moved permission decisions to a classifier. Mercury moved spend approval into card authorization. And Chrome shipped a CLI that moves browser control from a typed tool schema into a shell string. In every case the control got faster, more automatic, and less legible to the person who is still nominally responsible for it.

The tooling is doing what tooling does. It is removing friction, and friction was where you used to notice things.

So pick the profile before you install, not after. That single decision is most of your security posture for this tool, and it is the one nobody makes deliberately, because it happens in the thirty seconds when you are excited to try something.

Sources: ChromeDevTools/chrome-devtools-mcp, chrome-devtools-cli SKILL.md, repository security policy, Get started with Chrome DevTools for agents, Chrome DevTools (MCP) for your AI agent, Sept 23 2025, tool reference, npm package.