aindeev/agent-chrome-relay

面向需要让 Claude Code、Codex、Cursor 或 Paseo 完成带登录状态网页任务的开发者。它只支持 macOS，采用本地构建与白名单 Agent 的模式，是否值得投入取决于这两点是否契合你的环境。

解决什么问题

当 Agent 被要求邀请新成员、检查后台管理面板或完成一次结账时，往往卡在登录页或它够不到的浏览器步骤上。你只能把值复制到对话里，或者干脆手动重做。Chrome Relay 改变的就是这一步：Agent 在它自己打开的 Chrome 标签页里访问页面，用已登录的账号或共享的 1Password 库完成登录，再一路点击到完成条件。结果是任务真正做完，而不是停在一份半执行完的计划上。

有什么不同

中继是一个本地后台服务（127.0.0.1:9333，以 LaunchAgent 形式运行），通过 chrome.debugger 与 Go 编写的扩展通信。因此它不需要远程调试端口，Chrome 不会弹出“允许远程调试”的询问；但 Agent 工作期间，Chrome 会显示“Chrome Relay started debugging this browser”横幅。每个 Agent 有独立会话，只能看到自己打开的标签页，可能抬起或聚焦浏览器的命令会被吞掉，所以 Agent 无法把窗口拉到前台。可选的 do 命令更进一步：不再每次点击都走一轮模型，Agent 一次性说明目标，中继用保存的流程、Agent 自带的数据或 Claude Code 下的 Jev/Haiku 执行，再把结果交回给 Agent。代价是架构上的：每个驱动浏览器的 Agent 都连到同一个 Chrome 配置文件里的同一个扩展进程，而且这套机制是在你自己的 Mac 上构建并签名加载的，不是共享服务器。

登录辅助也不只是填密码。当 Google 登录流程中出现已登录的账号时，扩展会自己点击该账号和“继续/允许”；否则它会从你共享的 1Password 库中填入用户名、密码和两步验证码，包括每个输入框一位的拆分验证码。网站发到邮箱的验证码或链接会被读取并自动输入或打开。README 的安装页和一句话提示给出了两条不同的路径：把安装提示粘贴进 Claude Code、Codex 或 Cursor，或者手动克隆并运行 ./build。

谁值得试

适合已经在用这四个白名单 Agent 应用之一、经常需要处理公司登录后才可用的后台面板或内部工具，并且愿意安装一个本地签名服务的 macOS 开发者。对把凭据放在共享库里、希望 Agent 只能看到条目名而看不到值的人来说，1Password 集成会明显改变适用性。不适合 Linux、Windows 或混合设备环境，也不适合需要无头服务端浏览器的场景：项目明确要求 macOS 加 Google Chrome。想在容器里跑 Agent、不依赖本地 Chrome 配置文件的团队同样不合适。

使用条件与边界

第一个限制是平台：macOS、Google Chrome，手动构建还要求 Go 1.25 以上；Xcode 命令行工具只在 1Password 库和 Secure Enclave 通行密钥功能中才需要。第二个是访问控制：连接必须带上 ~/.chrome-relay/token 里的密钥，并且来自白名单进程名，中继通过 lsof/ps 检查；带浏览器 Origin 头的连接即使有密钥也会被拒绝。这是有意收窄的入口，不是通用远程控制 API。1Password 登录默认关闭，需要显式开启；后台标签页、Google 登录跳转和审计记录默认开启，可用 chrome-relay uninstall 移除。日常维护意味着改动后重新构建、保持 LaunchAgent 正常运行，并管理允许哪些 Agent 应用。README 没有记录 Windows 或 Linux 支持，不要自行假设。

HotRepo 点评

HotRepo 在 2026-10-24 首次记录该项目：它出现在新项目榜（并非总榜或每日 Trending 榜）第 17 名，总星数 281。这只是一个 14 天新项目的单日快照，无法据此判断热度能否持续。采用前请对照安装说明检查你的 Agent 应用是否在支持范围内，并确认你能接受 Chrome 的远程调试横幅。