Six agents, one Chrome: how my coding agents use a browser

I usually have several coding agents running at once in Conductor, some on Claude Code and some on Codex. A lot of their work ends in a browser. They check a deploy, click through a flow on a preview, change a setting in a dashboard that has no API, or read a doc behind a login.

Over the past few months I've given them a browser in most of the ways on offer and used each one heavily. Before writing this, I went back through my agent history to check my impressions against the record. I judged each tool by my own follow-ups more than by the agent's report, because an agent will happily call something verified that I later find broken.

The tools that did best gave each agent its own tabs or its own browser. The ones that struggled had several agents sharing the Chrome I was using myself.

Claude in Chrome#

Anthropic's Chrome extension didn't work out for me with Claude Code. I ended up dismissing dialogs on its behalf and asking whether it could see the page or click anything itself.

When I installed Garry Tan's gstack skills, the install prompt added a line to my Claude instructions: use gstack's browser for all web browsing and never use the Claude in Chrome tools. I kept it, and my Claude agents haven't touched the extension since.

The open issues on Claude Code's repository suggest it gets harder with several sessions: parallel sessions sharing one extension, one session's browser choice moving every other session, and no connection at all when Claude Desktop is installed, which it is on my Mac.

The ChatGPT extension works for one agent#

Codex drives Chrome through OpenAI's browser extension. The agent writes Playwright-style code that runs in my real Chrome, where I'm signed in to everything. At first it wouldn't connect from Conductor at all, and for a few days I was copying prompts between Conductor and the ChatGPT app, where it did work. Once it connected, it became my main tool for anything that needed my accounts.

With one agent driving it, it was also the most dependable browser tool I had. The best uses were jobs with no API behind them. One agent traced a change through a payment provider's dashboard logs, which its command-line tool doesn't show. Another rotated webhook secrets in a dashboard that has no API for them. It was quick at small jobs too: adding a DNS record took 80 seconds.

The problems started when there was more than one of anything: agents, accounts or windows.

One Chrome, one set of accounts#

The extension works in the Chrome profile where it's installed, with whatever I'm signed in to there. Agents kept landing in the wrong account. One needed a preview on my personal Vercel account while Chrome was signed in to my work one. Another reported that a slide deck was "access-denied in the connected browser, which only has your personal Google account signed in".

The agents also inherit everything else in my profile. My password manager was the most common blocker. While its popup was open, Chrome blocked the automation, and it kept reappearing as agents clicked into forms.

The extension can't target an Incognito window either. I once asked an agent to use Search Console only in Incognito, because my normal window was signed in to an account it shouldn't touch. It replied: "My Chrome tools don't expose a way to select or verify incognito tabs." I exported the data myself.

So I can't give two agents two different users on the same site. I often want exactly that, to test different features of the same product at the same URL.

Six agents, one Chrome#

With the extension connected, agents sharing Chrome mostly got along, because each works in its own named tab group. Now and then one claimed a tab I had open and navigated it somewhere else. The trouble came when the extension dropped. Codex then fell back to its computer-use tool, which drives Chrome through macOS accessibility and acts on whichever Chrome window is in front.

One afternoon the extension disconnected and six sessions fell back at once. Each brought its own window to the front, which pulled the others off their pages. One agent asked me: "Another agent may be controlling the same browser. Please pause any other browser-using agents so I can finish safely." Later it was still reporting that "native element IDs are becoming invalid between reads and clicks", and by the end it had spent the best part of an hour waiting for the others or for me. Another explained that "Native Chrome control follows whichever window you're using, so it keeps switching away from the preview."

The same fallback explains the Incognito mix-up I'd noticed. A week earlier, an agent had lost the extension and carried on in the front window, which happened to be Incognito. It had saved an environment variable in Vercel and submitted a sitemap in Search Console there without mentioning it.

A quiet log#

When something goes wrong, I want to see what the agent did, and the extension makes that hard. Its instructions tell the agent that when control is interrupted it should "not quote the raw runtime error. Summarize it naturally for the user". The record in Conductor is the code for each step, a short title the model wrote before running it, and whatever page dump the code printed. Screenshots stay inside the chat history instead of files I can open. In the computer-use fallback, most clicks target numbered accessibility elements, like click(817), which mean nothing once the page has changed.

During what should have been a read-only look around a sales tool, an agent clicked Share on a test quote and published it. Nobody was emailed, and I only know because the agent told me. None of the browser calls in that turn had titles.

The command-line tools leave more behind. The scripts sit in the workspace where I can read them, and gstack and Aside agents often saved screenshots to disk as they went.

It only works in Codex#

The extension belongs to Codex. If I move a task to Claude, because Codex has hit its usage limit or Claude suits the job better, the browser doesn't come with it. Claude sessions that picked up Codex's browser work had to import my cookies into a headless browser, ask me to do the clicks or use Aside. Once, a Claude session could only reach a doc through Codex, until Codex hit its usage limit.

The last click on money#

The rules around money depend on the tool. Codex's computer-use policy makes me press the final button on anything financial. The agent lines up the refund or payment in Chrome and waits for me to click. Through the extension alone, agents asked for my confirmation in chat and then clicked themselves.

Playwright gives the agent its own browser#

For everything else, Codex reaches for Playwright. It mostly uses a built-in skill that wraps Microsoft's Playwright CLI. Each named session is its own browser with its own cookies, and agents save login state to a file so later scripts can reuse it.

It was the best tool for checks I could state precisely. Agents measured where elements sat, stubbed network responses to reach error states, and ran real avatar calls on preview builds with fake microphone and camera input. One batch of scripted calls found a microphone permission overlay covering the Cancel button. Recently a Claude session kept one headless Chrome alive between steps and ran calls with a synthetic voice and face. On macOS the fake audio stayed silent until it turned off two of Chrome's audio-service features.

It was weaker as a pair of eyes. Agents reported layouts as verified at desktop and phone widths, and then I found a cropped call button or a chip sitting over content. One agent apologised: "My earlier visual sign-off was too generous." Headless Chrome also looks different to the sites it visits. PostHog filters out the HeadlessChrome user agent as a bot, which sent agents down the wrong path more than once. One told me a setting hadn't taken effect when it had.

The other problem was cleanup. One morning, with a lot of agents running, I asked one: "DO you keep spawning playwright chrome browsers? they are using 86gb or ram and crashing my computer". It had opened three headed Chrome windows in two minutes while trying to log in to a dev environment. It apologised and closed them. By the time another agent checked, there was nothing left to measure, so I can't blame all that memory on Playwright. The logs do show the habit, though: agents regularly left named sessions open, and Playwright CLI leaves headed browsers open until something closes them.

gstack, then Aside#

On the Claude side, browsing went through gstack's browse command, a headless Chromium the agent drives with short shell commands. It was reliable on local servers and on Vercel previews, where the agent could sign in with a test account.

It struggled with sites that needed my own login. gstack can import cookies from my Chrome, but that brings up a macOS Keychain prompt, and when I wasn't at my desk the agent sat waiting for it. More often than not, a session that needed a login to a site like GitHub, Stripe or Notion didn't get all the way in. A few agents also typed real passwords into commands, where they ended up in the transcript.

gstack now drives Aside first when it's installed. I only found out recently, when an agent told me "Aside isn't installed, so I'll use gstack's headless browser" and I asked what Aside was.

Aside is a Chromium-based browser from a Y Combinator company. It has its own agent, but I use it through its command line. aside repl runs Playwright-style JavaScript in my Aside browser, where I'm already signed in. Each script opens its own tabs, which sit together in an Agent Tabs group, and closes them when it finishes. The agents get my logins without touching the tabs I'm working in.

I've only used it for a few days, so this is an early verdict, but every task I've given it has worked. A full check of this site found that clicking through to the next post opened it 129 pixels down, with the breadcrumb hidden behind the header. That's fixed now. Another agent tested a dev environment end to end after a big change. It created a throwaway organisation, worked through the settings, ran a live avatar call, then deleted the organisation and switched my account back. And the doc stuck behind Codex's usage limit came through Aside in the end: I'd left it open there, and an agent read it in its own tab.

The agents asked before changing anything on a site that wasn't local. When a page needed a login, they stopped and asked me to sign in inside Aside. One noticed that clicking the cookie banner on this site would record a consent choice for me, and left it alone. Several Claude sessions have driven Aside at the same time without getting in each other's way.

There are rough edges:

• gstack's check for Aside failed every time after I installed the CLI, so agents fell back to the headless browser, usually blaming a slow start. The check stores its timeout command in a shell variable, and zsh doesn't split that into words, so it looks for a program literally called gtimeout 30. Two issues are open (#2842, #2904). Until it's fixed, telling the agent to use the Aside CLI directly works.
• Long scripts sometimes lost the connection. Keeping each script to about six pages helped.
• aside repl doesn't support every Playwright method, and its screenshots ignore emulated viewport sizes.
• I haven't tried separate accounts yet. Each Aside account has its own browser profile, and --account picks which one a command runs under. That's the closest thing I've found to giving each agent a different signed-in user.

What I look for now#

1. If an API or command-line tool can do the job, skip the browser. As I once told an agent: "you don't need chrome because I gave you keys".
2. Each agent gets its own tabs or its own browser, never the window I'm using.
3. The agent drives it from the shell, so it works from Claude and Codex and I can move a task between them.
4. Different agents can be different signed-in users on the same site.
5. It leaves a record: the script it ran and the screenshots it relied on, saved as files.
6. I do the sign-ins and the final click on anything involving money.
7. It closes what it opens.

Signed-in browsers carry a risk of their own. An agent in my profile has my accounts and reads whatever the page says, and Simon Willison's lethal trifecta warns against exactly that mix: private data, untrusted content and a way to send data out. Anthropic's own advice is to use a separate browser profile without access to sensitive accounts. Profiles signed in to test accounts would cover the fourth point and this one together.

If I wrote the rule down for my agents, it would say something like this:

Choose a browser by what the task needs.
 
If an API, CLI or connector can do it, use that instead.
 
For pages that need my signed-in accounts, use the Aside CLI
(aside repl). Work in your own tabs and close them when you're
done. I do the sign-ins; never type a password. Ask before
changing anything on a site that isn't local, and leave payments,
deletions and messages to me.
 
For local servers, previews and anything a test account can
reach, use headless Playwright in a named session. Use fake media
flags for calls. Close every session before you finish.
 
Never drive the Chrome window I'm using. Save the scripts and
screenshots you rely on in the workspace so I can check them.

What I haven't tried#

Researching this turned up tools built for the gaps I hit. I haven't used them, so these notes come from their docs.

• Playwright CLI has a show command that opens a grid of every running session with a live preview, so agents can stay headless while I watch all of them. Its state-save and state-load commands keep one login file per test user.
• Vercel's agent-browser gives each named session its own browser and can scope session names to a git worktree. Its 0.34.0 release fixed "parallel sessions sharing one Chrome hijacking each other's tabs", the same kind of clash I had with Codex.
• Google's Chrome DevTools MCP, which now has a CLI too, adds performance traces, network inspection and source-mapped console errors. Pages opened in an isolated context get their own cookies, so two users can be signed in to one site in the same browser.
• Cloud browsers such as Browserbase and Kernel run each session remotely with saved login profiles, which would take the memory off my Mac. Both warn against using one saved profile in two sessions at once. Kernel documents an SSH tunnel that puts my local dev server inside the remote browser at the same localhost address, so cookies and sign-in redirects still match.
• WebMCP lets a website register tools that an agent calls directly, instead of clicking through the page. Chrome has it in an origin trial from version 149 to 156, and ChatGPT's built-in browser supports it as site tools. An app could offer an agent a "create test organisation" tool on the page itself.

One detail from the research applies to all of them: cookies don't separate by port. Conductor gives each workspace its own localhost ports, but if two agents test localhost:3000 and localhost:3010 in the same browser profile, they share login cookies, and one agent signing in can sign the other out.

The gap I most want closed is still identity: two agents, signed in as two different users, testing the same page at the same time. Aside accounts, Playwright state files and isolated contexts all look like ways to get there.