你以为给 coding agent 配浏览器只能给它全权限？今天 Chrome DevTools MCP 把这件事的沙箱彻底原生化了

你把 Claude Code 或 Codex 接进 Chrome DevTools MCP，准备让它帮你做自动化测试——截图、录屏、看看控制台有没有报错。

结果 agent 拿到的是一个文件系统全开的浏览器：它想往哪里写文件就往哪里写，想读哪里就读哪里。你信任的是「帮我看看页面有没有 bug」，但它其实可以读写你 home 目录下的任何东西。

这不是夸张，是 chrome-devtools-mcp v1.9.0 之前每台机器都在发生的事。

这件事从上周开始彻底变了。

旧世界：给浏览器就等于给全盘读写

chrome-devtools-mcp 是 Google 官方维护的 MCP 服务器，让 coding agent 通过 Chrome DevTools 协议控制浏览器。v1.9.0（2026-09-08）之前，它的文件系统权限模型是这样的：

CLI 模式下，文件写入类工具（截图保存、带 –filePath 的截图、带 –outputDirPath 的输出）默认拥有完整的系统访问权限——没有目录限制，没有边界。它甚至在启动时打印警告说「当前运行在全权限模式下」，但很多 CI 脚本和自动化流水线从来不读日志。

MCP 协议模式稍好一点：如果你没有协商 MCP roots capability，文件写入会被限制在操作系统临时目录。但问题在于，大多数 MCP 客户端（包括 Claude Code 的内置集成）在初始化时根本不会主动协商 roots capability，所以服务器默认退回到「只写 tmp」的保守策略——但这一点极少有人知道，因为没有任何运行时警告。

两种模式，两套逻辑，互相不透明。对于安全敏感的自动化场景，这是个持续存在的盲区。

v1.9.0：文件系统沙箱现在有显式边界了

新版本引入了两个核心安全原语：

第一，–filesystemRoot（别名 –workspace）参数。你可以明确指定 agent 的文件写入工具只能访问哪些目录，超出边界的写入会被拒绝并报错 Access denied。配置路径会通过 MCP roots capability 协商生效，roots 为空时默认保留 tmp 目录。

第二，–allow-unrestricted-paths 标志。这个标志是显式的反向开关：加上它等于恢复旧版宽松行为；不加，则走安全路线。对于需要真正全盘访问的可信本地工作流，这个标志是有意为之的显式授权，而不是默认的意外开放。

对于 MCP 协议客户端，还有一个额外的守卫：即使配置了 –allow-unrestricted-paths，validatePath() 仍会做路径前缀校验，防止符号链接越权。路径必须落在 roots 范围内，否则即使 flags 开了也会被拒绝。

JS 执行也能关了：agent 不需要的那只手

除了文件系统沙箱，v1.9.0 还补了另一个安全缺口：JavaScript 执行工具。

–no-javascript-evaluation 标志在之前的版本就存在，但在 v1.9.0 中它的覆盖范围扩展了——现在同样作用于页面导航（navigations）和初始化脚本（initScripts）。换句话说，agent 拿到的是「只读浏览器」：它可以截图、读控制台、看网络请求，但没法往页面里注入脚本。

配合 –slim 模式（只暴露导航、截图、执行三件套），你可以把 agent 的浏览器能力精确切到最小表面——这对沙箱化自动化场景尤其有用。

怎么配才安全

最保守的配置：

bash
npx chrome-devtools-mcp@latest
–filesystemRoot=/path/to/project
–allow-unrestricted-paths=false
–no-javascript-evaluation

这样 agent 只能写 project 目录，只能读 tmp 目录，不能往任何页面注入 JS。

如果你用 Claude Code，在 ~/.claude/settings.json 或项目 .mcp.json 里配 args：

json
{
“mcpServers”: {
“chrome-devtools”: {
“command”: “npx”,
“args”: [“-y”, “chrome-devtools-mcp@latest”, “–filesystemRoot=/workspace/output”, “–allow-unrestricted-paths=false”]
}
}
}

MCP 客户端会在初始化时自动协商 roots capability，服务器收到后把文件写入限制在 /workspace/output 范围内。

为什么这件事值得认真对待

coding agent 接管浏览器是现在最常见的 AI 编程工作流。但浏览器插件天然是「代码执行 + 网络请求 + 文件系统写入」的三合一能力载体。如果你不做边界控制，agent 在帮你跑自动化测试的同时，完全可以写入 ~/.ssh/、读你的 GitHub token 环境变量，或者往 authorized_keys 里新增一行。

这不是假设的安全威胁，是真实的能力边界问题。chrome-devtools-mcp v1.9.0 把它变成了一个可以显式配置的工程问题，而不是依赖「客户端默认行为」或「agent 不会做坏事」的社会契约。

下一步：如果你在团队里用 coding agent 做自动化测试，先把 MCP 配置里的 –filesystemRoot 配上，再把 –no-javascript-evaluation 加上。信任但要验证——这句话对 AI agent 同样适用。