Translated from the original Japanese article
Tech 13 min read

Chrome DevTools MCP now supports connecting to existing browser sessions

Chrome DevTools MCP AI Security
IkesanContents

Increasingly, browser debugging is entrusted to coding agents. Chrome DevTools’ MCP server acts as a bridge, but until now you had to start Chrome with a dedicated user profile or explicitly connect to a remote debugging port. It was quite annoying that I couldn’t use Chrome, which I use for normal development work, as is.

The newly added --autoConnect option removes this restriction. MCP servers can now request connections while leaving existing Chrome sessions open.

What is Chrome DevTools MCP?

Chrome DevTools MCP is an MCP server that exposes Chrome’s DevTools functionality as a Model Context Protocol tool. Internally, it uses the Chrome DevTools Protocol (CDP) to communicate with the browser via WebSockets. When combined with coding agents such as Claude Code, Gemini CLI, Cursor, and Windsurf, agents can directly manipulate and inspect Chrome.

Specifically, the operations that the agent can perform are as follows.

  • Navigation to URL
  • Inspecting and manipulating DOM elements
  • Check network requests
  • JavaScript execution within the page
  • Take a screenshot
  • Check for console errors

The agent autonomously investigates problems such as The style of this element is strange'' or This API request is returning an error” and suggests corrections.

Why MCP and not CLI?

If you just want to leave browser operations to AI, there is also an approach via CLI such as Vercel Labs’ agent-browser. In fact, there is a strong opinion that “MCP eats up the context window, so CLI is sufficient.” In March 2026, Perplexity’s CTO Denis Yarats announced the transition from MCP to CLI/API, and Y Combinator CEO Garry Tan also indicated a policy to build a CLI instead of MCP.

The reality of context costs

MCP servers deploy tool definitions to prompts, so the more functional a server is, the more tokens it consumes. This problem has been verified quantitatively.

MetricMCPCLIDifference
GitHub operations (93 tool definitions)Approximately 55,000 tokensApproximately 200 tokens275x
Intune compliant tasks (50 devices)Approximately 145,000 tokensApproximately 4,150 tokens35x
Context inference usage rateApprox. 64%Approx. 95%-

In MCP, cases have been reported in which multi-step inference breaks down after 3 or 4 tool calls. This is because the tool definition pushes important information to the end of the context window. Tools to convert MCP to CLI, such as mcp2cli, have also appeared, with claims that they can reduce token costs by 96-99%.

Why did Google still choose MCP?

On the other hand, it is a misconception to view MCP as upwardly compatible with CLI. MCP is a “common protocol” and has a different design philosophy from specific CLI tools.

Comparison axisCLI (agent-browser, etc.)MCP (Chrome DevTools MCP)
Integration methodAgent executes shell commandCalls tool via protocol
Compatibility between agentsCommand interpretation differs for each agentCompatible with all agents with common schema
Tool discoveryAgent reads and understands helpServer provides structured list of tools
Context costLow (only necessary commands)Consumes tokens for tool definition
BidirectionalityDepends on parsing standard outputReturns as structured response

While the CLI is highly context efficient, there is no way to know in advance what the agent can do. You need to read agent-browser --help or write usage instructions at the system prompt. With MCP, the server provides the tool schema declaratively, so agents know what operations are available when they connect.

This is a major reason why Google chose MCP to integrate DevTools. With CLI, you need to support separate agents for Claude Code, Gemini CLI, and Cursor, but with MCP, one server can support all agents. Chrome also specifies an “MCP on the browser” that is independent of Anthropic’s MCP in WebMCP (/en/articles/chrome-jpeg-xl-pqc-webmcp), and has a consistent policy of positioning MCP as a common language between agents.

In terms of actual usage, I’m leaning towards making the CLI the default and having a fallback if specific MCP guarantees are needed. DevTools MCP is a case of “if it’s not an MCP”. Bidirectional communication is required, such as browser debugging session management, real-time DOM change notification, and multiple tab state management, which cannot be handled by simple command input/output.

—What autoConnect achieves

When you pass the --autoConnect option to the MCP server, the MCP server requests a remote debugging connection from the user data directory identified by the --channel parameter (stable by default) to the locally running Chrome instance.

Session reuse

You can continue to use your existing browser session, eliminating the need to log in again when debugging authenticated pages. While logged in to the service being developed, the work can be directly transferred to the agent. It can be used naturally to let agents check the actual display while fixing bugs on the dashboard screen.

Coordination with DevTools UI

Can access active debugging sessions in the DevTools UI. Agents can directly investigate the request selected in the Network panel or the element highlighted in the Elements panel. Instead of a human specifying, “Look at this network error,” you can simply select the request in DevTools and pass it to the agent.

Possible use case

In Google’s official documentation, it is used for debugging during development, but in reality it is expected to be used more widely.

Test automation for authenticated web apps

Run the E2E test on the agent while logged in to the staging environment using SSO. Previously, it was necessary to prepare a service account for testing or automate the authentication flow with Playwright, but with --autoConnect, the session after a human logs in normally can be passed as is.

Browser operation from OpenClaw

OpenClaw added the “Live Chrome session attachment” feature in the March 13, 2026 update. It is a feature that allows the OpenClaw agent to connect directly to a logged in Chrome browser session, and internally uses Chrome DevTools MCP.

OpenClaw’s browser control offers three modes.

ModeMethodApplication
Extension RelayControl existing tabs via Chrome extensionWork with logged in sessions
OpenClaw-managedIsolated Browser InstancesAutomation Tasks
Remote CDPCDP Direct ConnectDistributed Cloud Deployment

Extension Relay mode has the same idea as --autoConnect, and passes the browser with the human logged in as is to the agent. You can use it by saying “Please check the display of this URL” to an OpenClaw instance that is connected to Slack or Discord, and it will open a browser, take a screenshot, and send it back to you. GitHub Issue #16567 also requests the integration of network capture and Lighthouse auditing.

However, this is also quite dangerous from a security perspective. Given that the OpenClaw ecosystem itself has become a target for supply chain attacks, the scenario of a malicious skill accessing a browser session via the DevTools MCP is a realistic scenario. Snyk’s audit found that 1,467 (36.82%) of ClawHub’s 3,984 skills had security issues, and 76 were confirmed to be malicious. It is technically easy for a malicious skill to extract cookies and tokens from logged-in sessions via Extension Relay mode.

Security design and remaining concerns

Remote debugging is disabled by default. To enable it, you need to explicitly operate chrome://inspect/#remote-debugging, and Chrome will display a permission dialog for each connection request. A “Chrome is being controlled by automated test software” banner is displayed on the browser at all times during the session. Since Chrome 136, remote debugging with the default profile is blocked for security reasons, and this restriction must be intentionally lifted.

The GitHub README contains the following warning:

chrome-devtools-mcp exposes content of the browser instance to the MCP clients allowing them to inspect, debug, and modify any data in the browser or DevTools.

This design is intentional. Having access to your existing browser session also means you can access any services you’re logged in to. The risk of misuse is minimized by requiring users to explicitly enable it and approve each connection.

However, once the connection is established, the session remains alive. There are some open questions here.

Implicit delegation of authenticated sessions

Once you grant an agent access to DevTools, the agent can access any service that is logged into that browser. Gmail, GitHub, internal tools, banking sites. Using DevTools’ JavaScript execution feature, you can also retrieve the contents of cookies, localStorage, and sessionStorage.

graph TD
    A[ユーザーがリモートデバッグを許可] --> B[MCPサーバーがChromeに接続]
    B --> C[エージェントがDevTools APIを取得]
    C --> D[任意のURLにナビゲーション可能]
    C --> E[任意のJavaScriptを実行可能]
    C --> F[Cookie・localStorageの読み取り可能]
    D --> G[ログイン済みサービスに<br/>エージェントとしてアクセス]
    E --> H[認証トークンの抽出が<br/>技術的に可能]
    F --> H

The permission dialog only asks Do you want to grant debug access to this MCP server?'' There is no granularity as to which tabs” or “which operations” are allowed. It’s an all-or-nothing design.

This issue has the same structure as Microsoft Copilot’s Data protection policy bypass issue. Copilot was able to access confidential emails (contracts, personnel documents, legal documents) by bypassing the organization’s access control policies. The same thing happens with DevTools MCP, where AI was described as a new security vector that bypasses traditional access controls as a trusted intermediary. The agent uses the human session as a “trusted intermediary” and can access services that the human did not intend.

Attacks via prompt injection

What happens when an agent receives the instruction “Open and verify this URL” and that URL is a service that requires login? In an authenticated session, the agent accesses the page normally while logged in. There is no mechanism on the agent side to set a restriction such as “do not access this service.”

graph TD
    A[攻撃者がコードコメントや<br/>Issueに悪意あるURLを埋め込む] --> B[エージェントがコードを読む]
    B --> C[プロンプトインジェクションで<br/>URLを開くよう誘導]
    C --> D[認証済みセッションで<br/>攻撃者のページにアクセス]
    D --> E[ページ上のスクリプトが<br/>セッション情報を取得]
    D --> F[エージェントにJS実行を<br/>指示してトークンを抽出]

This is not a theoretical matter. In the Perplexity Comet vulnerability, malicious commands embedded in Reddit posts allowed agents to navigate account settings, extract emails, and retrieve one-time passwords. In visual prompt injection, research has shown that instructions hidden in fake CAPTCHAs fool vision-enabled agents 100% of the time.

Studies show that more than 72% of indirect prompt injections bypass model guardrails, and the combination of “agent autonomously operating the browser” design and prompt injection renders traditional web security (Same-Origin Policy, CORS) meaningless. Agents can bridge between sites with full user privileges.

Combined risk with Chrome zero-day

Chrome’s attack surface is rapidly expanding in 2026.

CVEComponentTypeCVSSPatch timing
CVE-2026-2441CSS/Blinkuse-after-free8.8February 2026
CVE-2026-2649V8Integer overflow-February 2026
CVE-2026-3909Skiaout-of-bounds write8.8March 2026
CVE-2026-3910V8Inappropriate implementation8.8March 2026
-MojoZero Day-March 2026

V8’s vulnerability allows code execution in the sandbox just by opening the page. When combined with the Skia vulnerability, it is possible to create an attack chain that goes from sandbox escape to OS-level arbitrary code execution.

An agent opening a URL via DevTools MCP carries the same risks as a human clicking the URL. In a design where agents autonomously crawl through URLs, humans do not visually check each URL. The scenario where the page opened by the agent contains a zero-day attack is especially serious when using an existing session with --autoConnect. This is because cookies and tokens from authenticated sessions may fall into the hands of attackers.

Practical measures when using Chrome DevTools MCP are as follows.

  • Using an isolated profile: Create a dedicated profile with --user-data-dir and log in only to services necessary for development. --autoConnect is useful, but it should not be used in browsers logged into unrelated services such as banking or email.
  • For development/test environments only: Do not use in a browser that contains authentication information for the production environment.
  • Agent output monitoring: Check the URLs accessed by the agent and JS execution logs. The Chrome DevTools MCP collects tool call statistics by default (you can opt out with --no-usage-statistics), but this is for sending to Google and not as an audit log for the user.
  • Content Firewall: Prompt injection detection combining regular expression pattern detection and LLM semantic analysis. However, complete protection is difficult

Setup instructions

Requires Chrome M144 or later (specify --channel=beta until M144 is promoted to Stable).

Step 1: Enable remote debugging

Open chrome://inspect/#remote-debugging in Chrome and follow the instructions in the dialog to enable remote debugging.

Step 2: Configure MCP server

Example configuration with Claude Code:

claude mcp add chrome-devtools --scope user -- npx chrome-devtools-mcp@latest --autoConnect

If you want to edit the JSON configuration file directly:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--autoConnect",
        "--channel=beta"
      ]
    }
  }
}

Similar settings can be made with other MCP-compatible agents such as Gemini CLI, Cursor, and Windsurf.

Step 3: Operation check

Try sending the agent a prompt that refers to the state of the browser, such as “Analyze the performance of the currently open page.”

Relationship with existing connection methods

--autoConnect is added as a complement, not a replacement, to existing connection methods. There are three conventional connection methods:

MethodApplication
Start Chrome with a dedicated MCP server profileTesting and automation in an isolated environment
Connect by specifying a remote debug portConnect to a CI environment or specific instance
Isolate multiple instances with temporary profilesParallel testing, environment that does not interfere with each other

If you want to use an existing authenticated session as is, --autoConnect is the simplest choice. However, “simple” does not equal “safe”. The use of dedicated and temporary profiles was designed to avoid exactly the security concerns described in this article. --autoConnect is a function that intentionally removes that isolation, and should be used only after understanding what you are giving up in exchange for convenience.

Personally, I think --autoConnect itself is a useful feature. However, when I see that OpenClaw advertises “real logins, one toggle, zero extensions,” I can see a future where “easy to use” just means “easy to exploit.” The warning text in the Chrome DevTools MCP’s GitHub README is lame to say the least, and I thought it should have written in bold: “You can access any data in your browser.”