BeatBrowser开源浏览器控制插件,让Codex、Claude Code等Agent共用已登录的Chrome
开源浏览器控制插件 BeatBrowser:让 Codex、Claude Code 共用你已登录的 Chrome
BeatBrowser开源了一套Chrome扩展和本地Node桥接,支持Codex、Claude Code、Cursor等Agent通过MCP操作用户已有登录态的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/[email protected]
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 用浏览器,登录态是怎么解决的?
- 有没有哪个站(特别是富文本编辑器)是你觉得现有工具都打不穿的?丢过来我们试试。
来源:V2EX · v2ex.com