Chrome DevTools MCP

The server holds no API keys or tokens of its own and does not forward client tokens. By default it launches Chrome with a dedicated profile under ~/.cache/chrome-devtools-mcp rather than the user's everyday Chrome profile, which is the only real narrowing of authority. That profile is persistent and shared across every session and project, the Chrome process inherits the full environment, and the browser can open any local file the OS user can read. Configuration handling that affects the profile, executable and connection target is not integrity-protected.

As a tool server, the host owns approval; this server's contribution is risk signalling. Every tool definition must declare readOnlyHint and the registration passes it to the client, and powerful tools (evaluate_script, navigation, input, file-writing tools) are marked not read-only. There is no destructiveHint, no preview or dry-run, and no server-enforced read-only mode or confirmation step. A wrongly approved call can submit forms or act on any site signed into the persistent profile, with no undo.

File paths handled by the server itself are validated well: canonical realpath containment against client roots or the OS temp directory, and writes opened with O_NOFOLLOW and mode 0600. URLs, however, are only checked against a small scheme denylist, evaluate_script accepts arbitrary JavaScript, and file: navigation is allowed by default, which lets the browser read files the path checks would have refused. The default tool set includes JavaScript execution, navigation and input; categories can be disabled but most are on.

Model-written JavaScript (evaluate_script, initScript, javascript: URLs) runs inside Chrome's page renderer rather than in the Node server, so the isolation comes from Chrome's own renderer sandbox, which this repo leaves enabled by default. That code still runs with the page's network access and the persistent profile's cookies. The sandbox is controlled by Chrome flags, and how launch options are sourced is not integrity-protected, which caps this criterion.

Page content (accessibility snapshots, console messages, network bodies, dialog text) is returned to the model as plain markdown-like text, in places right next to the server's own instructions, with no untrusted marker. Structured output exists but is experimental and off by default, and the project's security policy tells users to use trusted content or rely on the client. If a page hijacks the agent, the default tools let it read local files through file: URLs and read unredacted cookies and headers, send data anywhere with scripted fetches, and act on signed-in sites, all without the server asking anyone.

The server has no memory store. Configuration discovery and loading does not protect the integrity of security-relevant server options.

By default the server loads no plugins, but it has several paths for running third-party code: installing unpacked Chrome extensions, executing tools a web page exposes, WebMCP tools, an ffmpeg binary, and any Chrome executable path. The extension and page-tool categories are off by default. Nothing is pinned or integrity-checked, and configuration that can set the executable or enable these categories is not integrity-protected. A substituted executable runs as the same user with the full environment.

Usage telemetry is on by default but content-free: string parameters are reduced to length buckets and only tool names, latency and success are sent. Header redaction for network requests exists but is off by default, so cookies and Authorization headers go to the model provider in the default flow. The optional debug log records full tool parameters, and connection credentials are not reliably kept out of it. Because file: navigation is allowed, the model can also read long-lived keys such as SSH or cloud credentials from the user's home directory.

The server keeps no record of what it did unless the operator passes --logFile or sets NODE_DEBUG. When enabled, each tool call is written as a timestamped line with its parameters, but there is no structured format, no record of results, no actor attribution, and no tamper protection. Telemetry sent to Google is aggregate and is not an audit trail.

Every tool call is serialised through one mutex and bounded by a hard-coded 60-second timeout that configuration and the model cannot raise. Output sizes are capped for network bodies, console messages and request lists. The timeout only stops waiting: the abandoned browser work keeps running, and the server ignores MCP cancellation. Closing stdin or sending a signal shuts the server down and closes the launched browser, with a 5-second forced exit.