这是一篇给“重度前端/自动化工程师”的实操型笔记，聚焦 Chrome DevTools MCP 的安装、部署与长期可复用（固定 user-data-dir、持久化登录态与扩展）的使用策略。默认读者熟悉 CLI、CDP 与代理等概念。

背景

MCP（Model Context Protocol）的 Chrome DevTools 服务器让你的智能体/助手（Claude、Cursor、Copilot、Gemini…）直接操控真实的 Chrome，通过 CDP 做导航、点击、抓包、性能分析等。“关键不是能不能连”，而是如何把它做成一个稳定的、可重复、可持久的调试环境。官方 MCP 项目与博客见：(GitHub)

一页原理

• CDP 入口：Chrome 以 --remote-debugging-port=PORT 启动后在 http://127.0.0.1:PORT/json/version 暴露 webSocketDebuggerUrl；所有自动化（Puppeteer、DevTools、MCP）都从这个WS 连入。(Chrome DevTools)
• 安全变化（Chrome 136+）：出于 Cookie/数据防护，不再允许对“默认数据目录”开启远程调试；必须同时指定一个非默认的 --user-data-dir。否则端口形同无效。这也是“想继承日常登录态直接开调试端口却失败”的根因。(Chrome for Developers)
• user-data-dir vs profile：user-data-dir 是根；各 Profile（如 Default/, Profile 1/）是其子目录。我们推荐“为自动化单独建一个 专用 user-data-dir”，把它当“长期可复用的测试浏览器”。(Chromium Git Repositories)

部署：固定目录 + 固定端口

1) 启动一台“长期可复用”的 Chrome

# macOS，建议先彻底退出已有 Chrome
osascript -e 'tell application "Google Chrome" to quit' 2>/dev/null || true

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --user-data-dir="$HOME/.chrome-mcp" \   # 专用数据目录（长期保留）
  --remote-debugging-port=9222            # 固定端口，便于脚本化与接入

验证：

curl -s http://127.0.0.1:9222/json/version | jq .
# 应见到 webSocketDebuggerUrl

这台浏览器的 Cookie、扩展、站点权限、证书例外等都会保存在 ~/.chrome-mcp 下，之后每次复用即可。(Chrome for Developers)

2) 安装与接入 MCP（以通用客户端配置为例）

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["chrome-devtools-mcp@latest", "--browserUrl=http://127.0.0.1:9222"]
    }
  }
}

--browserUrl 让 MCP 接管已在跑的浏览器（而不是再拉一份临时无状态的）。这是“可复用环境”的关键。(GitHub)

把“临时玩具”变成“团队资产”

固化登录态与站点配置

1. 第一次用 ~/.chrome-mcp 打开后，人工登录你关心的域名（如：x.com、gmail、facebook等）；
2. 配好站点权限（通知、麦克风、剪贴板）、证书例外等；
3. 这些状态都会保留到下次（除非你清理目录或站点强制重新登录）。安全策略不允许直接“吸附到默认目录”，这是设计所致。(Chrome for Developers)

安装扩展（如 Ad Block、XPath Helper、React DevTools…）

• 用这台浏览器正常打开 Chrome Web Store 安装即可；扩展及其配置都会落在 ~/.chrome-mcp。
• MCP/智能体执行用例时就能直接使用这些扩展带来的 DOM 面板/辅助 UI（前提是场景允许）。

分环境策略

• 你可以为不同项目/客户创建不同的 user-data-dir（如 ~/.chrome-mcp-foo, ~/.chrome-mcp-bar），每个都固定端口与独立扩展组。
• 由外层脚本决定“今天挂哪一份目录 + 哪个端口”，再把 --browserUrl 指过去即可。

最小可依赖脚本（macOS）

用于“一键拉起 + 健康检查 + 输出 WS URL”。结合你自己的路径替换。

#!/usr/bin/env bash
set -euo pipefail
DATA_DIR="${DATA_DIR:-$HOME/.chrome-mcp}"
PORT="${1:-9222}"
APP="/Applications/Google Chrome.app"
BIN="$APP/Contents/MacOS/Google Chrome"

osascript -e 'tell application "Google Chrome" to quit' >/dev/null 2>&1 || true
mkdir -p "$DATA_DIR"

open -na "$APP" --args \
  --user-data-dir="$DATA_DIR" \
  --remote-debugging-port="$PORT"

for i in {1..25}; do
  if curl -fsS "http://127.0.0.1:$PORT/json/version" >/dev/null; then break; fi
  sleep 0.2
done

echo "DevTools: http://127.0.0.1:$PORT/json/version"

生产化建议（踩坑最少的路径）

• 永远用非默认 user-data-dir：Chrome 136+ 的强制要求；别跟它对着干。(Chrome for Developers)
• 固定端口与目录：让上层编排（MCP 客户端、CI、本地脚本）都能“靠约定接”（IaC 思维）。
• 把“探活”标准化：接入前先 GET /json/version，拿到 webSocketDebuggerUrl 再连，避免竞态。(Stack Overflow)
• 最小权限原则：扩展只装必要的；证书例外按域收敛；代理仅在需要时开。
• 隔离数据污染：不同项目分目录；必要时“只读镜像 + 运行时 overlay”（通过脚本复制模板目录启动）。Chromium 文档对目录结构有说明，可据此做模板化。(Chromium Git Repositories)

常见问题速查

• 端口没开/连不上
  • 忘了带 --user-data-dir → 按上文做；
  • 端口被占用 → 换号并同步 --browserUrl；
  • 同机多实例 → 用 open -na 或直接执行二进制，确保新进程接到 flag。(Chrome for Developers)
• 想“继承日常浏览器的 Cookie”
  • 现在不行（136+ 明确禁止默认目录远程调试）；最靠谱是“在专用目录首登一次”，或开 Chrome Sync 同步书签/设置（Cookie 仍以站点策略为准）。(Chrome for Developers)
• MCP 客户端起不来 Chrome
  • 某些客户端沙箱/权限问题时，让 MCP 连已在跑的浏览器（--browserUrl），别让它自己拉新实例。(GitHub)

结语

不要把 MCP 仅当“能连就行的玩具”。正确姿势是：固定 user-data-dir + 固定端口 + 可编排脚本，把这台浏览器当成“自动化测试工作站”。一旦首登/首配完成，之后就能以确定性的运行时承载你和智能体的调试、验收与性能分析——这才是“工程可用”的 DevTools MCP。

资料与参考：
Chrome DevTools MCP 官方仓库与博客（安装/能力/客户端示例），以及 Chrome 136+ 的远程调试安全变更、CDP 与用户数据目录说明等。(GitHub)