OpenClaw 接上 Chrome:使用用户的Profile,而不是新浏览器

我这几天把 OpenClaw 的浏览器链路重新折腾了一遍，最大的感受很直接：默认的 browser 很强，但它原来更像一个隔离出来的新浏览器，会话干净，代价就是和我真实在用的 Chrome 不是一个世界。像微信公众号后台、X、知乎这种已经登录好的站点，以前只能重新登录，其实从 2026.3.13 版本开始，OpenClaw 正式加了 existing-session，底层走 Chrome DevTools MCP，这个问题终于被正面解决了。

x.com

这篇分享给大家：怎么让 OpenClaw 接到你正在使用的 Chrome，会话、标签页、登录态都直接复用，然后真的去帮你操作。

· · ·

MCP 在这里到底解决了什么

如果只看以前的默认路径，OpenClaw 的 browser 更像一个由它自己托管的浏览器 profile。这个模式的优点是干净、稳定、隔离，做通用自动化非常合适；但问题也很明显：你在本机 Chrome 里已经登录好的站点，它不知道；你已经打开的标签页，它也看不到；你当前会话里的 cookie，它更不会复用。

而 existing-session 这条路，本质上是让 OpenClaw 通过官方 Chrome DevTools MCP attach 到一个正在运行的 Chromium 会话。它不是再起一个新浏览器，而是贴到你正在用的那个浏览器上。所以它带来的变化不是“浏览器工具更快一点”，而是能力模型变了：

• 能看到你当前已经打开的标签页
• 能直接复用登录态和 session cookie
• 对“谷歌账号登录”的场景终于可用了
• 对需要接着你当前上下文干活的任务，比如从现有标签页继续点、继续填、继续截图，也终于顺手了

说白了，MCP 在这个场景里的价值，不是让 OpenClaw“多了一个浏览器工具”，而是让它第一次真正接进了真人浏览器环境。

第一步：浏览器配置

这个模式不是靠旧式 relay 插件，现在也可以卸载这个插件了，因为从3.23版本开始，已经停用了插件的支持。按官方文档，它依赖的是 Chrome DevTools MCP 的 auto-connect 流程。实际操作时，浏览器侧有三件事要确认：

1. Chrome 版本要够新，文档里写的是 144+
2. 打开 chrome://inspect/#remote-debugging，启用 remote debugging

inspect 配置页

OpenClaw 配置

OpenClaw 文档里其实已经给了方向：默认 profile 还是 openclaw，也就是它自己托管的独立浏览器；如果你想让 agent 优先使用真实登录态浏览器，就要把 defaultProfile 切到 user，并把这个 profile 的 driver 设成 existing-session。

"browser": {  "enabled": true,  "defaultProfile": "user",  "profiles": {    "user": {

      "cdpUrl": "127.0.0.1:9222",
      "driver": "existing-session",      "attachOnly": true,      "cdpPort": 9222,      "color": "#00AA00"    }  }}

这里我想把“必须项”和“我自己的机器设置”分开说一下：

• defaultProfile: "user"
  这是让 OpenClaw 默认优先走真实用户浏览器的关键
• driver: "existing-session"
  这是 MCP attach 模式本身
• attachOnly: true
  只 attach，不自己起新的 Chrome
• cdpPort: 9222
  这是我这台机器当前 Chrome 已经在用的调试口写法，不是 existing-session 唯一必须项
• color
  纯粹是为了在 UI 里更好认

还有一个官方文档里特别值得记住的点：如果你用的官方Chrome，端口是9222，可以不配 cdpUrl。 如果你接的不是默认 Chrome，而是 Brave、Edge 或其他 Chromium 分支，官方给的正解是配 userDataDir，不是再倒回旧 relay 思路。

测试

这个地方我建议不要一上来就让 agent 去点生产页面。最稳的测试顺序其实很朴素：

记得改完配置要重启。

openclaw browser --browser-profile user startopenclaw browser --browser-profile user statusopenclaw browser --browser-profile user tabsopenclaw browser --browser-profile user snapshot --format ai

按官方文档，成功的判断信号其实很明确：

• status
   里能看到 driver: existing-session 的效果
• 传输方式是 chrome-mcp
• 运行状态是 running: true
• tabs 能列出你当前已经开的网页

我自己实测下来，status、tabs、snapshot、截图、只读 JS evaluate、无害的 click / type / press 都是通的。也就是说，日常最常用的那条链路已经够完整了。

获取标签页

怎么跟你的 OpenClaw 说

我后面专门把这个操作方式设成了默认，还补了一条经验：gateway 或 browser 刚重启时，如果第一次 browser 调用超时，不要立刻判“浏览器渠道故障”，先用轻量命令复测一次。 这条经验很值钱，因为 attach 刚起来那几秒，确实可能出现假性失败。

实际下指令时，我建议把下面几层意思说完整：

• 明确写 profile=user
• 明确写“复用我当前 Chrome 的登录态，不要走隔离浏览器”
• 如果是第一次接，先让它跑 status 和 tabs 再开干

用 browser 工具连 user profile，先列出我当前 Chrome 的 tabs。如果已有系统标签页，就直接在那个标签页里继续操作。复用我现在的登录态，不要走 openclaw 隔离浏览器。

或者你也可以更保守一点：

先用 profile=user 跑 status 和 tabs。确认 attach 成功后，再打开微信公众号后台页面并继续操作。

这个差别看起来只是多打了几个字，但对 agent 来说很重要。因为你不说，它很可能还是按默认隔离路径理解你的需求；你说清楚了，它才会真的去用那条有登录态的 live session。