Chrome DevTools MCP Now Lets AI Agents Write Files Freely

Chrome's October 2026 developer update reads like routine release notes: new heap inspection tools, a plugin system, console tweaks. The one line worth stopping on is buried near the bottom: Chrome DevTools MCP, the server that lets AI coding agents drive a real Chrome browser, now ships with unrestricted file access turned on by default. The news is not the feature list. It is the direction of the change, three months after the same tool had to patch a bug that let files escape its sandbox in the first place.

The Default Flip Happened in One Line of a Changelog

Chrome DevTools MCP is the official Google-maintained bridge between AI coding agents and a real Chrome instance. It lets a model call tools like navigate_page, evaluate_script or upload_file instead of just reading static code, which is what makes agents useful for debugging a live site instead of guessing at it.

The project's changelog for version 1.9.0, shipped September 8, 2026, lists it in five words: "Add --allow-unrestricted-paths by default for CLI." According to the server's own configuration docs, that flag's documented default is false, and without it, "file-writing tools are restricted to the OS temp directory when no roots are configured." Turn the flag on, and the server can write wherever the process has permission to write, not just a disposable temp folder.

That distinction matters because almost nobody runs chrome-devtools-mcp as a bare library. Chrome's own setup instructions point developers to the command-line entry point, launched with npx, which is exactly the surface this change affects. The library's documented default of false hasn't moved; the way most people actually start the server has.

MCP's "Roots" Capability Was Supposed to Prevent This Exact Problem

The Model Context Protocol, the open standard behind this whole category of agent tool, already has an answer for file-access scope. Its specification defines a "roots" capability that lets a client, such as Claude Code or Cursor, tell a connected server exactly which directories it is allowed to touch, and the spec requires clients that support it to declare that capability during setup.

The catch is in that word "support." Roots negotiation is optional for clients to implement, and chrome-devtools-mcp's own documentation acknowledges the gap directly: it recommends enabling unrestricted paths "only when connecting a trusted local client that does not implement MCP roots and requires access to paths outside the temp directory." In plain terms, the safety mechanism exists in the protocol, but enough popular coding agents don't speak it yet that the server's maintainers decided the fallback restriction was breaking more workflows than it protected. The same gap between how fast agent tooling ships and how fast its guardrails catch up shows up in how quickly coding-agent vendors retire and replace their own models: the tooling layer moves faster than anyone's ability to fully vet each change.

That's a real tradeoff, not a mistake. A temp-directory-only default means an agent can't save a screenshot, a performance trace or a heap snapshot into your actual project folder, which is the whole point of connecting a browser to a coding agent in the first place. Widening the default is the path of least resistance for a tool whose users mostly run it locally and already trust the agent sitting on top of it.

This Is the Same Code That Had a Symlink Escape Bug Three Months Earlier

What makes the timing worth a second look is what happened in June 2026. GitHub's own advisory GHSA-8qf9-62x2-82pp, assigned CVE-2026-53766, describes a path-validation bypass in the function that was supposed to enforce those filesystem boundaries, McpContext.validatePath(). The function checked a requested path against the allowed root folders by textually resolving it, but it never followed symlinks first. A symbolic link placed inside an allowed root could point to a file outside it, pass the textual check, and then get followed anyway on the actual read or write, including through the server's upload_file tool, which can send an out-of-root file to whatever page the browser currently has open.

The bug affected versions 0.24.0 up to, but not including, 1.1.0, carried a CVSS v3 score of 6.1 (medium), and was fixed in 1.1.0. A second, related advisory, GHSA-3pvj-jv98-qhjq, covered a similar symlink issue in how the server wrote its daemon.pid file inside its temp-directory fallback. Both were published within a day of each other, on June 15 and 16, 2026.

So the sequence is: the project's temp-directory sandbox had a symlink-shaped hole, the project closed it, and three months later the project shipped a CLI default that removes the sandbox for most users anyway. Neither step was reckless on its own. Together, they're a useful case study in how quickly a hardening fix can be undone by a usability fix on the same codebase.

Microsoft's own security researchers have made a related point about the industry at large: in Microsoft's 2026 Digital Defense Report, the gap between how fast attackers exploit a weakness and how fast defenders close it is the central problem, not any single vulnerability. A tool that patches a boundary bug and then loosens that same boundary by default three months later is a small-scale version of exactly that gap.

Who Actually Needs to Check Their Setup

This is not a story about Chrome the browser, and it's not a story about every AI tool. It is specifically about developers who have wired an AI coding agent into chrome-devtools-mcp for browser automation or debugging. If that's not your setup, you can skip the rest of this and move on.

If it is your setup, a short checklist is more useful than general anxiety:

• Check how you launch the server. If your MCP client config runs it through npx chrome-devtools-mcp or chrome-devtools-mcp@latest on the command line, you're on the CLI path this default change affects.
• Check whether your coding agent negotiates MCP roots. Claude Code, Cursor, Gemini CLI and similar tools vary in this; consult your client's own MCP documentation rather than assuming.
• If you want the old, narrower behavior back, set --filesystemRoot to your actual project directory instead of relying on the temp-directory fallback, and leave --allow-unrestricted-paths off.
• Update to at least version 1.1.0 regardless of the above; that's the release that closed the symlink bypass, and anything older carries that specific bug.
• Remember the server's own README warning: it "exposes content of the browser instance to the MCP clients," so avoid pointing it at a browser profile with sessions or data you wouldn't want a connected model to see.

The Honest Counterargument: This May Be the Right Tradeoff

The strongest case against treating this as alarming is that the project did everything a responsible maintainer can do short of leaving the restriction on. The change is documented in the changelog and the configuration guide, not hidden. It's scoped to the CLI entry point rather than silently changing the library's programmatic default. And the guidance is explicit that it's meant for "a trusted local client," which describes the overwhelming majority of chrome-devtools-mcp installs: a single developer, on their own machine, running an agent they already gave broad permissions to elsewhere.

There's also a scale argument. An agent like Claude Code or Cursor typically already has direct file-system access on your machine independent of any browser MCP server. A coding agent that can already read and write your repository doesn't gain much additional risk from a connected browser tool that can also write files, since the bigger door was already open. Viewed that way, this default change mostly closes the gap between two tools that were already operating at similar trust levels, rather than introducing a new category of exposure.

Where that argument gets weaker is prompt injection. If an agent is browsing a page whose content it treats as instructions, even partially, an unrestricted file-write capability raises the ceiling on what a manipulated response can do, compared to a tool confined to a disposable temp folder. The project's own fixed CVE shows that boundary enforcement in this exact codebase has already failed once under adversarial conditions. Trusting the new default requires trusting that it won't fail again, on a wider attack surface, before anyone notices.

What to Watch Next

Treat this as a template, not a one-off. MCP servers that bridge coding agents to browsers, databases, cloud consoles and CI systems are shipping defaults under the same pressure: roots adoption among clients is uneven, and every maintainer facing that gap has to choose between a safer default that breaks workflows and a permissive one that doesn't. Chrome DevTools MCP picked permissive for its CLI path this time. The next tool you add to an agent's toolchain may make the same call without saying so as plainly as this changelog entry did.

The practical takeaway is to stop assuming an MCP server's security posture is static. Re-check filesystem and permission defaults after every version bump on tools your agents can reach, the same way you'd re-check dependency permissions after a security incident, and don't assume a tool that shipped safely a few months ago still ships that way today.

Sources

• New in DevTools: October 2026 (Chrome Developers blog)
• ChromeDevTools/chrome-devtools-mcp (GitHub repository and changelog)
• chrome-devtools-mcp security advisories (GitHub)
• Model Context Protocol specification: Roots