Google's Chrome DevTools team has shipped an update to its Chrome DevTools MCP server that enables coding agents to connect directly to live, active browser sessions rather than isolated instances they spin up themselves. Available in Chrome M144 (currently in Beta), the feature introduces a new remote debugging flow: users first enable remote debugging via chrome://inspect/#remote-debugging, then configure the MCP server with a --autoConnect flag. Chrome enforces explicit consent through a permission dialog on each connection request and displays a "Chrome is being controlled by automated test software" banner throughout. Agents can reuse authenticated sessions — bypassing sign-in gates — and access active DevTools contexts such as currently selected Elements panel nodes or flagged Network panel requests, enabling handoff between manual and AI-assisted debugging workflows. The official blog post, authored by Chrome DevTools engineers Sebastian Benz and Alex Rudenko, uses Gemini CLI as the reference coding agent in all configuration examples.
The announcement landed with notable skepticism on Hacker News, where experienced developers working with <a href="/news/2026-03-15-godex-building-a-free-ai-coding-agent-with-mcp-servers-and-local-llms-via-ollama">coding agents</a> argued that MCP as a protocol is structurally ill-suited to heavy agentic workflows. The core criticism is that MCP tools permanently consume context window space, while CLI-based alternatives are faster, more composable, and better supported by model pretraining. Playwright with headed or headless Chromium was repeatedly cited as the pragmatic alternative, offering full browser automation and DevTools-equivalent inspection without MCP's overhead. Commenters described using tools like <a href="/news/2026-03-15-coderunner-local-vm-isolated-sandbox-for-claude-code-and-ai-agents-on-macos">Claude Code</a> with Playwright to intercept and map full API surfaces of live applications — workflows that have already diverged significantly from the official MCP approach.
The most significant disclosure in the thread came from Paul Irish, a long-tenured Chrome DevTools engineer at Google, who revealed that the project has quietly shipped a standalone CLI — chrome-devtools-cli, at version v0.20.0 — in the same repository as chrome-devtools-mcp. Irish surfaced the tool not through an official announcement but directly in response to MCP's token-cost criticisms, positioning the CLI as an alternative that provides the same browser debugging capabilities without the protocol overhead. The official blog post makes no mention of the CLI whatsoever, creating a visible gap between Google's curated public narrative and what individual engineers on the team have already built. A version number of v0.20.0 indicates the tool had gone through meaningful iteration before receiving any public attention.
What Google chooses to do next with chrome-devtools-cli is the open question. At v0.20.0, the tool is not a prototype — it has shipped, iterated, and gone unannounced. Whether Google folds it into official documentation or continues to let it exist quietly alongside the MCP server will say something concrete about how seriously the Chrome DevTools team takes the token-cost objections its own engineers are raising.