Chrome Relay Hands Coding Agents Your Logged-In Chrome, and Its Locks Face the Door

aindeev/agent-chrome-relay is a careful piece of engineering. Read its security section for what it guards, then build your setup around what it doesn't.

Every coding agent eventually hits a login wall. The headless browser it launches has no cookies, no sessions and no idea who you are, so the agent can read the public web and nothing behind a sign-in. The obvious fix is to let the agent use the browser you already have, the one signed into your email, your cloud console, your bank and your company's admin panels.

aindeev/agent-chrome-relay, sitting at #6 on Trendshift this morning, is that fix done thoughtfully. It lets Claude Code, Codex, Cursor and Paseo drive background tabs in your everyday Chrome on a Mac, "with your real logins." What stands out about it is how honest its README is about the shape of its protection. The locks are real. They are on the front door. Once an agent is inside, it is in a browser that is you.

How it works

Three pieces, per the README:

The agent-browser CLI (the Apache-2.0 npm package) talks over WebSocket to a relay service on 127.0.0.1:9333, installed as a macOS LaunchAgent.
The relay talks to a Chrome extension that attaches chrome.debugger to the agent's tabs. It uses the debugger API rather than a remote-debugging port, so nothing listens for DevTools connections beyond the relay itself.
A chrome-relay CLI handles setup, identities, diagnostics and the audit log.

Agent tabs open inactive in a collapsed "Agents" tab group, so nothing steals your focus. Commands that could raise the browser are dropped. Tabs idle for 30 minutes close themselves. The repo is MIT, roughly 250 stars, with no tagged releases; the extension manifest says version 0.8.1.

The locks, and which way they face

The relay runs two checks on every connection. First, a secret generated at setup and stored in ~/.chrome-relay/token with mode 600. Second, an allowed-app check: it inspects the connecting process with lsof and ps, looks for environment markers the agent apps set (such as CLAUDECODE), and walks parent processes. It refuses connections that carry a browser Origin header and only accepts its own extension ID.

That is a good answer to the question "which program on this Mac may drive my Chrome?" A random web page cannot. A stray local script probably cannot. The README draws the limit itself: "It is not a boundary against malware already running as you, which could read the secret and fake the markers."

It also scopes tabs between agents. Each agent sees and controls only the tabs it opened, popups included, and a safety net adopts stray tabs an agent page spawns. Two agents cannot trample each other or your own tabs.

What none of that addresses is the question I care about more: what may an authorized agent do once it is in its own tab?

The answer is close to anything you could do. The extension requests debugger, scripting, identity and <all_urls> host access in its manifest. The CLI it relays for, agent-browser, has commands for eval <js>, cookies, cookies set, local and session storage, and upload. Chrome Relay's README does not say whether it filters any of those, and its audit trail explicitly records "the agent's own scripts," so script execution is in play. Inside its tab, the agent's requests go out with your cookies to whatever site it opens.

Sign-in is handled the same way. If the right Google account is already signed in, the extension "clicks the account and Continue/Allow itself." Passwords, passkeys, two-step prompts and signed-out accounts stop the flow and return SIGN-IN NEEDED, and the bundled skill tells the agent never to type credentials. That is a sensible line. It also means every account already signed into that profile is one click away for the agent, with no prompt to you.

Why this matters more than it looks

Coding agents read untrusted text all day: issues, READMEs, web pages, tool output. Prompt injection is the standing risk of that job. A headless browser with no sessions caps the damage of a successful injection at "read some public pages." A browser holding your logins removes the cap. The agent's tab can reach your inbox, your GitHub settings or your billing page with your authority, and the relay's process checks have no opinion about any of it, because the process asking is the legitimate agent.

This is the same lesson as the Grok Bot story that circulated this week, where xAI's own docs tell users not to treat separate bots as a security boundary. Isolation between agents is not isolation from the agent.

The skill file has good rules: don't print the connection secret, don't install anything, stop at login forms. It has no rule about confirming purchases, sending messages or changing settings. Those rules would be instructions anyway, and instructions are exactly what an injected page tries to override.

Put this into practice

If you want what Chrome Relay offers, and the login wall is a real cost, here is the lowest-friction way to get it without handing over your whole online life.

Create a dedicated Chrome profile for agents. The extension installs per profile, so install it only there. Sign that profile into the specific accounts a task needs and nothing else. Your bank and personal email never enter it.
Use identities.json deliberately. The relay picks accounts from ~/.chrome-relay/identities.json. Map agent work to low-privilege or test accounts where the service offers them.
Prefer read-only roles. For dashboards and consoles, give the agent profile an account with viewer permissions. A read-only session limits what a hijacked tab can change.
Read the audit trail after sessions. chrome-relay audit reads ~/.chrome-relay/audit/YYYY-MM-DD.jsonl, with the app, session, working folder, pages, clicks and scripts. The README says agent actions are recorded there, and it is the only after-the-fact record you get. Check it the way you would check a shell history after letting someone use your laptop.
Keep public browsing headless. The skill already says pages that need no login can use plain agent-browser open. Make that your default and reach for the relay only when a session is required.
Run chrome-relay doctor and keep it updated. It is a young project with no releases; git pull plus chrome-relay update is the upgrade path.

Honest limitations

I want to be fair to this repo, because it is better than most tools in its category. It names its threat model out loud, logs typed text only as a character count, strips query strings from logged URLs and refuses to type passwords. Those choices show care.

The limits are still real. It is macOS only and needs Chrome, Node 20+ and agent-browser. It has no tagged releases. The README does not document whether eval, cookie reads or uploads pass through or are blocked, so check the relay source before assuming either way. The allowed-app check rests on process inspection and environment markers that, by the author's own statement, anything running as you can fake. And the audit log records what happened after it happened; it does not stop anything.

Most of all, the tool cannot fix the underlying trade. An agent with your sessions has your authority. No relay design changes that; only the scope of the sessions does.

Your call

Chrome Relay solves a real problem, and it tells you plainly where its protection ends. The decision left to you is which logins sit behind that line. Give the agent a profile that holds only what this week's tasks need, and the worst outcome of a bad page becomes small and recoverable. Give it your everyday browser, and you have made every page the agent reads a potential operator of your accounts.

Sources: aindeev/agent-chrome-relay README · extension manifest · skill/SKILL.md · vercel-labs/agent-browser · Trendshift

Medium metadata

Title: Chrome Relay Hands Coding Agents Your Logged-In Chrome, and Its Locks Face the Door
Subtitle: aindeev/agent-chrome-relay is a careful piece of engineering. Read its security section for what it guards, then build your setup around what it doesn't.
Tags: AI Agents, Browser Automation, Security, Claude Code, Prompt Injection
Canonical URL: fervorai.dev (import from the published post)
Reading time: about 7 minutes