让 Codex 操作已登录 Chrome，先选对这 3 条路

你让 Codex 或 Claude Code 去验一个线上页面，最常见的断点不是代码，而是登录。

测试环境有 SSO，后台要二次验证，支付页还绑着设备。把 Cookie 倒进一个新开的自动化浏览器，看上去像走了捷径，下一秒往往又回到登录页。更麻烦的是，有些网站会把会话和设备里的私钥绑定，复制过去的 Cookie 到期后根本续不了。

这不是「自动化工具不够聪明」。Chrome 已经在推进 Device Bound Session Credentials：网站可以要求浏览器用设备里的密钥续签会话。于是你把登录信息复制到另一个 Profile，得到的只是一次性的门票，不是原来那把钥匙。对要过 SSO、设备信任或二次验证的站点来说，连接原浏览器往往更符合它本来的安全模型。

这两天看到 Browser Use 的一篇整理，把 Claude Code、Codex、Gemini CLI 和 Cursor 接入已登录 Chrome 的路子列了六条。名单不难记，真正容易选错的是权限：你到底只想让 Agent 看一个标签页，还是把整套日常浏览器交出去？

我更愿意按这个问题拆。工具名会换，权限边界不会。

第一条路：只交出你选定的标签页

如果你的任务是「让 Agent 复现这个已登录的 bug」「检查这个内部工单页面」「在 staging 里点完一条验收路径」，优先选标签页级别的连接。

目前最清楚的一条是 Playwright MCP 的扩展模式。装好 Chrome 或 Edge 扩展后，MCP 服务用 --extension 启动。第一次连接时，由你选择交给 Agent 的标签页；它复用该标签页的登录态，但并不天然看见其他窗口。

{
  "mcpServers": {
    "playwright-extension": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--extension"]
    }
  }
}

这一条的价值不在「终于能自动化」，而在默认收窄了事故半径。你正在验公司后台，就只选后台那张 Tab；开着邮箱、网银和私人文档的窗口，不该因为一次 UI 回归测试顺手变成 Agent 的上下文。

配置前也别跳过一个现实问题：测试账号和生产账号是不是混在同一个 Chrome Profile 里？如果是，先把测试账号单独登录到一个工作 Profile，再把那张 Tab 交出去。这样即使 MCP 配置写错、任务跑偏，最坏的结果也更接近「测试数据被改了」，而不是「线上订单被操作了」。权限设计不是只看工具有没有确认框，还要看你把哪种身份放在了确认框后面。

对前端调试来说，这种拆分还有额外好处：复现录屏、控制台报错、请求瀑布图和最终截图都留在同一条任务路径里。Agent 不需要替你猜测试环境在哪，你也不用在一堆新开的无登录窗口里找回当时的状态。它更像把一个明确的浏览器现场递给同事，而不是把办公室钥匙串扔过去。

这个差别放在日常开发里很实在。比如产品同学报来一个「登录后价格没刷新」：你把测试账号所在页面交给 Agent，让它刷新、点开 Network、截一张复现图，任务到这里就该结束。它不需要知道你另一个窗口里正在写什么，也不需要拿到整个浏览器的历史记录。能力和任务刚好对齐，后面排查问题时也更容易说清楚：它看过什么、做过什么。

原文里提到，扩展模式默认会要求批准连接，也能通过 token 改成预授权。我的建议很朴素：需要长期、低风险、固定站点的自动化时再考虑预授权；临时排障先让那个确认弹窗留着。多点一次，不丢人。

第二条路：只用一种 Agent，就用它自己的扩展

如果你只用 Claude Code，并且本来就在 Claude 的付费计划内，Claude in Chrome 是阻力最小的选择。安装扩展、登录 Claude Code，再运行 claude --chrome，它会在可见窗口里处理浏览器任务。官方把它定位在「构建—测试—验证」这条线上：终端里改代码，浏览器里看页面、读控制台和网络状态。

在 ChatGPT 桌面应用里，Codex 也有自己的 Chrome 扩展。它适合要让 Codex 使用已登录浏览器状态的桌面端任务；文档默认要求你在新站点上确认权限。这里要留一个细节：这不等同于给 Codex CLI 装了浏览器。桌面应用和 CLI 是两条不同的接入面，别把一边的能力想当然搬到另一边。

团队里常见的误会是，把「浏览器能被 Agent 用」当成一个统一开关。其实它至少有三层：你的 Agent 是谁，连接的是哪个浏览器 Profile，以及它可以操作哪些站点。原生扩展把前两层包装得更省心，却不会替你回答第三层。上线前要验内部域名，和让它代你逛所有已登录网站，完全不是同一种授权。

这条路的好处是少配 MCP，坏处也很明确：你会被某个 Agent 的订阅、系统和产品边界绑住。Claude in Chrome 的文档就列出了限制，例如 API key、Bedrock、Google Cloud 等登录方式不走这条通路；碰到登录页和 CAPTCHA，仍需要人回来接手。

所以它适合「我就用这一套，而且想马上开始」。要是团队里有人用 Codex、有人用 Cursor、有人还在 Gemini CLI，别急着把所有人塞进同一种扩展。

第三条路：让 Agent 看整个浏览器，但先把日常账号挪开

Chrome DevTools MCP 的自动连接、Browser Harness，以及部分 CLI 的「连接现有浏览器」模式，解决的是另一种需求：你不只要一个页面，还要控制台、网络请求、多个页面间的跳转，甚至完整的已登录 Profile。

这时能力很强，边界也最宽。以 Chrome DevTools MCP 的连接文档 为例，自动连接需要在 Chrome 里开启远程调试确认；它连接的是已有浏览器，而不是专门新建的自动化 Profile。你得到的是更完整的调试视野，也要承担「默认 Profile 里有什么，它就可能看见什么」的后果。

这里别只盯着「会不会误点删除」。网页本身也可能带提示注入：一封邮件、一个客服工单、一段文档里的隐藏指令，都可能试图把任务拐去不该去的地方。给 Agent 一个已登录浏览器，等于给了它和你相近的操作面；权限弹窗、域名白名单和人工确认不是流程累赘，是最后几道护栏。

有一个小判断可以放在任务开始前：这次是否需要读取敏感内容，是否会发送、付款或删除，是否必须跨多个网站？前两个只要有一个答案是「是」，就把自动动作改成「Agent 准备、你确认」；第三个答案是「是」，先缩到专用 Profile，再看能不能把域名列成白名单。不是所有流程都值得端到端无人值守，尤其是登录态本身就是权限。

如果确实需要全浏览器连接，我会先建一个专用 Chrome Profile：只登录工作里必须的几个系统，不放金融、医疗、私人邮箱和管理员账号。用完断开连接或关掉远程调试。这样即使 Agent 看错了页面，损失也被锁在一个较小的盒子里。

不知道怎么选，就照这个判断

先问自己：这次任务必须读到哪些登录态？

• 只需验一个内部页面或复现单个流程：选 Playwright MCP 扩展模式，交出指定 Tab。
• 只使用 Claude Code 或 ChatGPT 桌面应用，并且接受其订阅与平台边界：用各自原生扩展，保留默认的站点确认。
• 必须看网络、控制台和跨标签流程：才考虑 DevTools MCP、Browser Harness 一类的整浏览器连接；先用专用 Profile，再给域名和动作加限制。

还有一个容易漏掉的收尾动作：任务结束后断开扩展连接，或关掉远程调试。很多配置最初是为排一个小时的故障开的，结果在本机安静地留了几周。把它写进测试清单里，比事后回忆「那个端口是不是还开着」靠谱得多。

别把「新浏览器不方便登录」理解成「真实浏览器必须全交出去」。中间还有一层标签页权限，往往正好够用。

这类能力接下来只会越来越常见。真正值得养成的习惯不是多背几个 MCP 配置，而是每次接入前都问一句：这项任务需要的是登录态，还是需要我整个数字生活？

你现在给编程 Agent 接浏览器时，最怕的是重复登录，还是权限一不小心开太大？