开源浏览器控制插件 BeatBrowser：让 Codex、Claude Code 共用你已登录的 Chrome

TL;DR ：BeatBrowser 是一个 Chrome 扩展 + 本地 Node 桥接，让 Codex 、Claude Code 、Cursor 这类 Agent 通过 MCP 操作你正在用的那个 Chrome（已有登录态），每个任务在独立窗口里跑，可以随时暂停、接管、清理。MIT 开源，不需要账号。

项目链接： https://github.com/BeatAPI/BeatBrowser

先回答这个帖子一定会被问的问题：官方已经有 Claude in Chrome 、Codex 也能直接操作浏览器，为什么还要做这个？

我一直会在 Codex 、Claude Code 、Cursor 之间来回切，有时还要让跑在云主机上的 Agent 用浏览器。官方插件体验很好，但各自只服务自家 Agent ，同时还会出现人与 agent 抢浏览器的问题；我想要的是一套浏览器工具，几家 Agent 共用，登录态还是我日常那个 Chrome。人与 Agent 有各自的使用空间。

扩展方案常被吐槽的几个问题，以及我们的处理

浏览器扩展方案的几个痛点，我觉得说得挺准，这几个问题我们自己也都踩过：

问题	我们的做法
Agent 乱开 tab ，跟你的标签页混在一起	每个任务开独立窗口（ TaskSpace ），页面有名字（ main / reference ），每个 owner 最多 4 个未结束任务、每个任务最多 16 页
人和 Agent 抢同一个窗口	你点进任务窗口，后续自动化就暂停；在侧边栏选择"接管 / 继续 / 停止"
扩展重载、浏览器重启后状态全乱	任务记录持久化；重载后未完成任务恢复为暂停，不会自己接着点；浏览器重启后要你显式关联页面，URL 相同不等于同一个页面
跑完一堆页面没人收拾	一键清理只关 Agent 开的页面，你关联过、接管过、移动过的页面受保护
卡在扫码 / 验证码 / 2FA	`ask` 工具把页面交回给人，你处理完再继续

架构

Agent (Codex / Claude Code / Cursor ...)
   │  stdio MCP （也有 CLI 和 Node SDK ）
   ▼
本地桥接  ws://127.0.0.1:18899   token 校验 + 本地审计日志
   │  WebSocket
   ▼
Chrome 扩展（ MV3：debugger / tabs / scripting / sidePanel ...）
   │  CDP
   ▼
你选定的那个 Chrome profile （已有登录态）

不导出 Cookie ，不迁移 profile ，也没有 BeatBrowser 云服务和遥测。
24 个 MCP 工具：snapshot / read_text / query / screenshot 、navigate / tabs 、act / click / type / fill / select / key / scroll / wait 、network / fetch / download / upload 、ask / status / learnings / spaces 、eval / reload 。
act 支持批量步骤，带 repeat {steps, until, max}、if {cond, then, else}、assert {cond}。分页、可选弹窗、状态检查可以一次下发，不用"调一个工具、看一眼、再调一个"。
learnings：站点笔记和 playbook 存在本地 ~/.beat-browser/learnings/，下次同一个站不用从零摸索。这是可复用的上下文，不是模型训练。

云端 Agent 也适配，可以使用你本地的 Chrome

Agent 跑在云上，浏览器留在你电脑上。走你自己的 Cloudflare Tunnel ，加 Bearer 认证，每个 Agent 一份独立凭证。我第一次把两个云端 Agent 接上来，两边第一次调用都列出了我本机同样那 11 个标签页，不用重新登录。云端模式暴露 21 个工具（去掉了本地文件类工具和 learnings ）。

适配 muse 和 grok bot 这种云端 agent ，我自己的使用体验，他们的云电脑重新登录的使用体感远不如我自己已有登录态的 chrome 。

和现有方案的对比

Claude / Codex 内置浏览器和官方插件：也能用已登录网站，原生体验更好；区别是只服务自家 Agent 、接入层不开源、需要厂商账号。
ego lite：思路很好，每个任务的 Cookie 隔离比我们干净；区别是它是一个新的 Chromium 浏览器，要把 Chrome 数据迁过去。我们是扩展，留在原来的 Chrome 里。
Playwright MCP / Browser Use：测试和脚本自动化很强；没有"Agent 在你旁边干活"需要的任务界面（进度、暂停、接管、清理）。
agent-browser 也能连已有浏览器，也有 Dashboard ，能力上不缺，主要是使用方式不同。

对比的是接入方式和文档写明的能力，不比模型、不比速度（我们没做同条件 benchmark ，不想编数字）。各家原始来源在仓库 docs 目录里的 COMPARISON 文档。

安装

需要 Node.js 20+、Chrome 116+、一个能启动本地 stdio MCP 的客户端。

npm install --global @beatapi/beat-browser@1.4.1
beat-browser install --dry-run   # 先预览会改哪些客户端配置
beat-browser install
beat-browser extension           # 打印扩展目录

然后在 chrome://extensions 打开开发者模式，加载已解压的扩展，重启 Agent ，跑 beat-browser doctor --json，看到 ok: true 和 extensionOnline: true 就好了。第一个任务建议给只读的。

待更新问题

扩展目前是手动加载，还没上 Chrome 商店；需要装 Node 本地工具，不是"装个插件就完事"。
任务窗口共享同一个 profile 的 Cookie 。同一个站要两个身份，得开两个 Chrome profile 。
暂停只能挡住后续动作，挡不住已经发出去的那一步；网站自己的弹窗还是可能抢焦点。
最小化窗口的有头截图是已知缺口；富文本编辑器、文件选择器这类原生弹窗还不完整。
扩展权限很大（debugger、<all_urls>），请只接你信任的 Agent ，重要操作保留人工确认。
主要在 macOS 上验证。没有 macOS 专属依赖，Windows / Linux 理论上可用，但还没有完整测试矩阵，欢迎帮忙踩坑。

扩展、桥接、MCP server 、CLI 、SDK 全部 MIT 开源。

想请教大家两个问题：

你现在让 Agent 用浏览器，登录态是怎么解决的？
有没有哪个站（特别是富文本编辑器）是你觉得现有工具都打不穿的？丢过来我们试试。