How to Make Your Agents and Your Browser Friends

For close to a year, my agents and my browser were strangers who kept bumping into each other. The agents never knew which browser they'd get, whether it was logged in, or whether it would answer at all. The browser never knew which agent was driving, or as whom. Everything shared one window and wore the same face. And I kept being surprised that nobody could tell who was who.

I got this wrong nine different ways: a fleet of supervised browser servers, an official plugin that stayed enabled for eight whole days, a script that copied my real Chrome profile somewhere automation could touch it, Claude's Chrome extension, and two more I'd rather not talk about. One of those sat in my config for months and was never called once. I even window-shopped the hosted agent browsers. They solve this properly, in someone else's cloud, holding my credentials. No thanks.

What I never did was write down what an agent actually needs from a browser. Here's the list I should have written on day one.

1. It can't need you to click Allow

My first note on the subject, sent one morning with a screenshot of the dialog:

why it keeps asking me this permission, I want to allow it permanently

The trap is that when you attach automation to your already-running Chrome, newer versions gate that connection behind a human clicking Allow. And the grant dies with the browser. One morning Chrome restarted at 08:46. The next scheduled run found the grant gone. Nobody was there to click. The handshake timed out, and the job logged a failure and moved on.

(A browser you launch yourself, with its own profile and its own debug port, never shows this dialog. That detail turns out to be the whole fix.)

A browser that needs a human present is really just your browser, on loan, while you watch.

2. It has to behave the same headless

I didn't know to ask for this one. It cost me the most.

Claude's Chrome extension pairs with an interactive session. Run headless (cron, dispatchers, anything unattended) and its browser tools are simply not there. Same machine and same Chrome, even the same working directory: ask an interactive session and the tools are present; ask claude -p and they're gone. Sixteen of my scheduled runs logged the same line: claude-in-chrome MCP absent.

So the tools existed only when I happened to be watching.

My nightly Vercel job found this out for me. It lost its browser and complained in eleven consecutive runs. Twice it wrote NEEDS HUMAN: browser path will not self-heal. On day ten it wrote down three options. One of them was the exact fix. I silenced the alert instead. Ten quiet days later, I typed this in genuine confusion:

why it was failing in daily job, but worked here without issues

The answer had been sitting in a log file for thirteen days.

3. Logins have to survive

Obvious, and still the first thing most tools give up.

My first setup died exactly here. Its final commit flipped every browser to "isolated": true. I fixed instability by throwing away the logins, which were the whole point of the setup.

The failure is easy to miss. A tool starts a fresh empty profile, hits a login wall, and reports success. From my own logs: agent-browser IS installed and works but runs a fresh temp profile → vercel.com/login wall, no session.

Everything ran fine; it just wasn't signed in as anyone.

4. Accounts must not mix

Two weeks before I built anything, I offered my agent my own Chrome, and caught myself mid-sentence:

I am logged into prod on chrome, use that, but I have already 3 orgs, will it work ?

Isolation, multiple profiles and port numbers sound like three separate problems, but they're really one. An identity is a set of logins that needs somewhere to live and a name of its own.

So each identity gets its own profile folder and its own fixed port. agent-browser, the CLI that drives a browser over its debug port, connects to whichever identity you name:

chrome-wrapper new ecomitram --label "EcoMitram"
agent-browser --cdp $(chrome-wrapper-ecomitram --port) eval "document.title"

Each port has exactly one set of logins behind it, so choosing a port is choosing whose account you act as. Point at the wrong one and you hit a login page instead of succeeding as the wrong person.

One rule keeps that promise honest: an account lives in exactly one identity. If the same account is signed into two of them, a wrong pick still works and you never find out.

5. You have to tell them apart

Headless-first tools skip this part, because it's a problem for me rather than for the machine. I asked for it by name:

I wanted to see the CHROME PROFILE in title

Three identical "Google Chrome" windows in Cmd+Tab. One is yours. Two are agents, logged into different accounts. That's the mistake you make at 11pm.

So each identity becomes its own Mac app with its own name, icon and colour, a separate app in the switcher rather than another window in the pile. The icons are how I look at my screen and know who's about to act as whom.

6. A human has to be able to drive it

If you can't drive the agent's browser yourself, you'll eventually stop trusting it.

Each identity is also a command: chrome-wrapper-ecomitram launches or focuses that window. You sign in once, by hand, and every agent inherits the session. Creating an identity needs me at the terminal. So does deleting one. On purpose: one wants a human to sign in, the other throws logins away.

This is also where it finally clicked: there were two jobs all along. Testing your own builds wants a clean, logged-out browser. The real internet wants an authenticated one. Every tool I'd tried was straining to be both. That's why my "which browser?" rule needed five rewrites in four months. One version lasted four days.

7. The sites have to let you in

Nobody writes this requirement down until they've been blocked. I asked early:

will it be detectable that agent is driving the chrome?

Automation flags alone stopped being enough years ago. Detection now weighs your GPU, your network fingerprint, your behaviour. That's bad news for headless stealth setups, but good news here, because a real Chrome, on a real profile, with a session you signed into yourself, isn't imitating a person's browser, it is one.

That's not a bypass:

basically you are saying we are running chrome with stealth power ?

No, there's no stealth in it, because nothing is pretending. At my volume, a few dashboard reads and a scheduled job, it just works. Push it to scraping volume and you'll get blocked like everyone else. Fair enough. Scrape at volume and you want a hosted service. I don't.

8. You have to own the path

The seven above are requirements, and this last one is the reason they're finally met.

Every previous answer belonged to somebody else: Anthropic's extension, someone's harness, a plugin, a hosted cloud. When the extension turned out to be interactive-only, I learned it from a job that had been broken for weeks while reporting OK. When Chrome v136 shipped, it stopped allowing debugging on your default profile, which killed one approach. A later version added the Allow gate from requirement 1, and there went another. None of that was mine to fix, only to work around, until the workaround broke too.

Your daily browser is a shared human thing that keeps moving underneath you, and an agent can't build on that. Owning the path doesn't stop things breaking, but it decides who gets to fix them. Chrome moves, and I move with it on my own schedule.

The list is the point

Nine answers in a year, each solving a slice, none covering the whole set. Not because the tools were bad, but because I kept fixing whichever symptom was loudest that week, instead of writing down what an agent's browser has to be.

If you run agents against real accounts, walk your setup down the eight. Mine failed 1, 2 and 4. A year ago I couldn't have told you that.

What I ended up with is one bash script, macOS only: github.com/ssv445/claude-skills, under bin/. You don't even have to install it yourself. Paste this to your agent:

Install chrome-wrapper by following
https://raw.githubusercontent.com/ssv445/claude-skills/main/bin/install-chrome-wrapper.md

The agent does everything except one step: signing in. That step is yours, at your terminal, on purpose. If you've read this far, you'll recognize that as the whole idea. The script is the easy part.

I spent a year making my agents and my browser share everything. One profile, one window, one set of logins, one name. I called it collaboration. It was a hostage situation.

Friendship turned out to be simpler: each side understands the other, and each knows how to interact. The agent knows which browser it's getting and as whom it acts; the browser knows who's driving. And I can tell everyone apart across the room.

Happy Friendship Day. Introduce your agents and your browser properly.