为什么你的 AI Agent 无法访问你已登录的工具，以及如何解决

我通常会在 Mac 上同时运行很多编程 Agent。大多数并不需要浏览器；但一旦某个需要，往往就会打断我正在做的事。

Agent 会在我打字时把标签页切到前台，或者 Chrome 会询问“允许远程调试？”再或者，Agent 会使用自己的无头浏览器，因此完全没有我的登录状态。它无法打开我们的管理控制台或预发布环境。任何位于 Google SSO 之后的内容都无法访问，这排除了我需要它检查的大多数东西。

现在，我使用 Chrome Relay，让 Claude Code、Codex、Cursor 和 Paseo 可以从命令行驱动我日常 Chrome 中的后台标签页，并使用我的真实登录状态。今天，我将它开源。

我对 Agent 使用的浏览器有四项要求。

• 它必须能通过 CLI 工作。我使用的每个 Agent 都能运行 shell 命令；但有些无法使用浏览器扩展或 MCP server。

• 它必须使用我实际的、已经登录的 Chrome 配置文件。我不想复制配置文件，也不想再次登录一个全新的浏览器。

• 它必须保持在后台。我在同一个 Chrome 中工作，因此窗口切到前台或弹出对话框都会造成中断。焦点必须保持在我指定的位置。

• 它必须足够快。如果检查一个页面需要 20 秒，Agent 就不会再去做这类检查。

显而易见的选项都至少无法满足其中一项要求。

大多数浏览器工具会连接 Chrome 的调试端口。这会触发“允许远程调试？”提示。

我原本以为，把 Chrome 配置文件复制到另一个浏览器中就能解决问题。但 Google 会将会话绑定到设备。将 Cookie 复制到另一个浏览器后，Google 会将其视为无效。你会从原本想使用的应用中被登出。

我还尝试过 Playwright 扩展和单独的已登录浏览器。它们各自覆盖了我部分需求，但没有一个能满足全部四项要求。

Codex 和 Claude 自己的 Chrome 扩展会使用一个小型扩展，并调用 Chrome 的 chrome.debugger API。这种方法可行。它们的扩展只能与各自的应用通信，因此我希望将同一能力作为标准 DevTools 端点暴露出来，供任何 CLI Agent 使用。

连接关系如下。

agent-browser (CLI) ──ws──▶ relay (127.0.0.1:9333) ──ws──▶ Chrome Relay extension ──chrome.debugger──▶ agent tab

该扩展采用 MV3，在每个 Chrome 配置文件中加载一次。它会将每个 Agent 标签页作为非活动标签页，放入折叠的“Agents”标签组中，并通过 chrome.debugger 执行 DevTools 命令。由于不使用调试端口，Chrome 不会询问“允许远程调试？”

Relay 是一个小型本地服务。它为每个 Agent 提供各自的 DevTools 端点，并丢弃任何会将浏览器窗口置前或聚焦的命令。一个 Agent 只能看到自己打开的标签页，因此我可以同时运行许多 Agent，而不会让它们互相干扰。

我使用 chrome-relay CLI 完成设置并获取某个配置文件的连接 URL。它还可以运行诊断并读取审计记录。

Agent 使用 Vercel 的 agent-browser CLI，并将其指向 Relay。

agent-browser --cdp "$(chrome-relay url you@company.com)" open https://app.example.com/
agent-browser snapshot -i     # 页面中的按钮、链接和字段，每项都有一个 ref
agent-browser click @e5
agent-browser close

邮箱地址用于选择 Chrome 配置文件。大多数情况下我使用工作配置文件；当 Agent 需要检查控制台中的内容时，则使用管理员配置文件。

弹窗和“在新标签页中打开”的链接会变为由同一 Agent 拥有的隐藏标签页。OAuth 弹窗仍然可以向打开它们的页面回传结果。

Google 登录也需要做一些处理。当网站跳转至 Google，且正确的账号已经登录时，扩展会自行点击账号和“继续”。Agent 永远不会输入凭据。如果跳转流程进入密码、Passkey 或两步验证页面，它就会停止。Agent 会提示我在自己的窗口中登录。

1Password 会带来一个不那么明显的问题。Chrome 会从包含其他扩展框架的任何页面中移除扩展的调试器连接，其中包括登录表单上 1Password 的菜单。Relay 会等待扩展重新连接，因此 Agent 的命令执行时间会稍长一些。

速度对我最重要。一条命令大约需要 0.15 秒；打开一个页面大约需要 0.6 秒。我的 Chrome 本来就已打开，因此无需启动浏览器。

我正在让 Agent 访问一个我登录了所有服务的浏览器。我希望知道哪些程序可以连接，以及 Agent 连接后做了什么。

每个连接都必须通过两项检查。它需要使用设置过程中生成的、每台机器独有的密钥，该密钥仅对你本人可读。发起连接的进程还必须是 Claude Code、Codex、Cursor 或 Paseo。Relay 会查找该进程，并检查这些应用在其子进程上设置的标记。即使网页拥有该密钥，也会被拒绝。

只有你自己的扩展副本可以作为扩展进行连接。Relay 会检查其来源，并确认连接进程是 Chrome。

这些检查可阻止其他本地工具和网页接入，并避免意外情况。不过，如果恶意软件已经以你的用户身份运行，它可能读取密钥并伪造这些标记，因此这并不能构成针对它的安全边界。

当 Agent 工作时，Chrome 仍会显示“已开始调试此浏览器”的提示栏，这与 Codex 扩展的行为相同。

每一次 Agent 操作都会写入审计日志。日志会记录页面和点击，以及按键和 Agent 自身的脚本。截图和登录点击同样会被记录。输入的文本仅以长度形式保存；Agent 输入的具体内容不会进入日志文件。当 Agent 表示它检查了某项内容时，我可以准确查到它做了什么。

目前它仅支持 macOS 和 Chrome。你需要 Node.js 20+ 以及 agent-browser（npm i -g agent-browser）。设置大约需要两分钟。

git clone https://github.com/aindeev/agent-chrome-relay
cd agent-chrome-relay
bin/chrome-relay setup

在 Agent 应使用的每个 Chrome 配置文件中，打开 chrome://extensions，启用 Developer mode，点击“Load unpacked”，然后选择 extension 文件夹。运行 chrome-relay doctor 检查所有配置。或者，也可以将网站中的设置提示粘贴给你的 Agent，让它引导你完成这些步骤。

设置过程还会将一个 skill 链接到 Claude Code，因此每个仓库都知道如何使用它。对于 Codex 和 Cursor，请在全局 Agent 指令中添加一行，指向同一个 skill 文件。

你可以在一次部署后，让它在预发布页面上试用；或者让 Agent 检查一项管理员设置。位于 SSO 之后的仪表盘也是不错的起点。让 Agent 使用你的 Chrome，然后在它检查时继续自己的工作。欢迎回复告诉我你让它访问了什么，或者哪里出了问题。

该仓库采用 MIT 协议：https://github.com/aindeev/agent-chrome-relay。网站为 https://agent-chrome-relay.aindeev.com。我也在 X 上，账号是 @AlexeyIndeev。

Alexey

I usually have a lot of coding agents running on my Mac at once. Most don't need a browser. When one does, it tends to interrupt whatever I'm doing.

An agent would bring tabs to the front while I was typing, or Chrome would ask "Allow remote debugging?" Or the agent would use its own headless browser and have none of my logins. It couldn't open our admin console or a staging environment. Anything behind Google SSO was out, which ruled out most of what I needed it to check.

I now use Chrome Relay to let Claude Code, Codex, Cursor and Paseo drive background tabs in my everyday Chrome, with my real logins, from the command line. Today I'm open-sourcing it.

I had four requirements for an agent's browser.

• It had to work through a CLI. Every agent I use can run shell commands; some can't use a browser extension or an MCP server.

• It had to use my actual Chrome profiles, already signed in. I didn't want to copy a profile or log into a fresh browser again.

• It had to stay in the background. I'm working in the same Chrome, so a window coming forward or a dialog is an interruption. Focus has to stay where I put it.

• It had to be fast. If a page check takes 20 seconds, agents stop doing them.

The obvious options each failed at least one requirement.

Most browser tools attach to Chrome's debugging port. That gets you the "Allow remote debugging?" prompt.

I expected copying my Chrome profile into a separate browser to work. Google sessions are bound to the device, though. Copy the cookies to another browser and Google treats them as invalid. You're signed out of the apps you wanted to use.

I also tried a Playwright extension and separate signed-in browsers. Each covered some of what I needed, but none met all four requirements.

Codex's and Claude's own Chrome extensions use a small extension with Chrome's chrome.debugger API. That approach worked. Their extensions only talk to their own app, so I wanted to expose the same thing as a standard DevTools endpoint that any CLI agent could use.

The connection looks like this.

agent-browser (CLI) ──ws──▶ relay (127.0.0.1:9333) ──ws──▶ Chrome Relay extension ──chrome.debugger──▶ agent tab

The extension is MV3 and loads once in each Chrome profile. It opens every agent tab as an inactive tab in a collapsed "Agents" tab group and runs DevTools commands through chrome.debugger. Without a debugging port, Chrome doesn't ask "Allow remote debugging?"

The relay is a small local service. It gives each agent its own DevTools endpoint and drops any command that would raise or focus the browser. An agent only sees the tabs it opened, so I can run many agents at once without them stepping on each other.

I use the chrome-relay CLI for setup and to get a profile's connection URL. It also runs diagnostics and reads the audit trail.

The agent uses Vercel's agent-browser CLI, pointed at the relay.

agent-browser --cdp "$(chrome-relay url you@company.com)" open https://app.example.com/
agent-browser snapshot -i     # the page's buttons, links and fields, each with a ref
agent-browser click @e5
agent-browser close

The email picks the Chrome profile. I use my work profile for most things and an admin profile when an agent needs to check something in a console.

Popups and "open in new tab" links become hidden tabs owned by the same agent. OAuth popups can still report back to the page that opened them.

Google sign-in needs some handling too. When a site bounces through Google and the right account is already signed in, the extension clicks the account and Continue itself. Agents never type credentials. If the hop reaches a password, passkey or 2-step screen, it stops. The agent tells me to sign in in my own window.

1Password causes a less obvious problem. Chrome drops an extension's debugger from any page containing another extension's frame, including 1Password's menu on a login form. The relay waits while the extension re-attaches. The agent's commands take a little longer.

Speed mattered most to me. A command takes about 0.15 s; opening a page takes about 0.6 s. My Chrome is already open, so there's no browser to launch.

I'm giving agents access to a browser where I'm signed in to everything. I want to know what can connect and what the agents did once they got in.

Every connection has to pass two checks. It needs the per-machine secret generated by setup, stored readable only by you. The connecting process also has to be Claude Code, Codex, Cursor or Paseo. The relay looks up the process and checks the markers those apps set on their child processes. Web pages are refused even if they have the secret.

Only your own copy of the extension can connect as the extension. The relay checks its origin and confirms that the connecting process is Chrome.

These checks keep other local tools and web pages out, and guard against accidents. Malware already running as you could read the secret and fake the markers, so this doesn't provide a boundary against it.

Chrome still shows its "started debugging this browser" bar while agents work, the same as with Codex's extension.

Every agent action goes into an audit log. It records pages and clicks, along with keys and the agent's own scripts. Screenshots and sign-in clicks are logged too. Typed text is stored only as a length; what an agent types never ends up in a log file. When an agent says it checked something, I can look up exactly what it did.

It's macOS and Chrome only for now. You need Node.js 20+ and agent-browser (npm i -g agent-browser). Setup takes about two minutes.

git clone https://github.com/aindeev/agent-chrome-relay
cd agent-chrome-relay
bin/chrome-relay setup

In each Chrome profile your agents should use, open chrome://extensions, turn on Developer mode, click "Load unpacked" and pick the extension folder. Run chrome-relay doctor to check everything. Or paste the setup prompt from the site into your agent and let it walk you through all of this.

Setup also links a skill into Claude Code, so every repo knows how to use it. For Codex and Cursor, add one line to your global agent instructions pointing at the same skill file.

Try it on a staging page after a deploy, or have your agent check an admin setting. A dashboard behind SSO works as a starting point too. Ask the agent to use your Chrome and keep working while it checks. Hit reply with what you pointed it at, or what broke.

The repo is MIT: https://github.com/aindeev/agent-chrome-relay. The site is https://agent-chrome-relay.aindeev.com. I'm on X at @AlexeyIndeev too.

Alexey