The Agent Browser card

An agent that writes a web app cannot see it. It can read its own code, run its own tests, and still ship a page with the submit button behind the keyboard, because at no point did anything look at the rendered page.

The Agent Browser is a real browser, running on your host, that the agent drives directly: it opens a URL, reads the page, clicks, types, and looks at the result. No browser extension, no plugin, no separate automation stack to install and keep alive. It is part of Offsite, and the agent already has it.

It is also a card. So while the agent works, you watch the page move on your board, and you can reach in and take over at any point.

The Agent Browser as a tile on the card of a Claude session: the shop page the agent just built — The agent opens the page it just built in its Agent Browser, clicks through it, docks it beside the terminal and tries it at phone and tablet sizes, while you watch from the Mac and the iPhone. A 50-second film, with sound.

The two browser cards. The Browser is yours and private to each device; the Agent Browser is one browser on the host that the agent drives and everyone can see.

What it is good for

The agent checks its own work. It opens the dev server it just started, reads the page, clicks through the form and looks at the result. The round trip that used to need you, look at this and tell me what broke, runs without you.

Nothing to install. No Chrome extension, no signed-in browser profile handed to a robot, no Playwright or Puppeteer setup that has to be maintained next to your project. The browser and the tools that drive it come with the Offsite host: it installs and updates its own copy of Chrome, the Offsite Agent Browser, on the machine the agent is working on, and your own Chrome stays untouched.

You watch, and you can take over. The stream shows a pointer and a click ripple wherever the agent acts, so the card tells you what is happening to your app right now, not afterwards in a summary. Click into it and it is a browser: scroll, type, navigate. The agent’s next command continues in the same page.

Every screen size, without the hardware. Responsive is the default and behaves like a browser window: the page reflows to whatever size the card has. The agent switches to a device when it tests a layout: iPhone SE, iPhone 15, 15 Pro Max, iPad mini, iPad, iPad Pro 11″ or 13″, Desktop 1280×800, Desktop HD, each with the touch and mobile behaviour the real device has. The card’s settings take it back to Responsive.

One browser, all your devices. Log into your staging environment on the Mac, pick up your phone, and you are still logged in, on the same page, at the same scroll position. Close the app entirely and come back: the page is where you left it.

It runs where there is no screen. The browser is headless, so a Linux VPS with no desktop is a perfectly good host.

It lives on the agent’s card

By default the Agent Browser is not a separate card at all: it docks to the card of the agent that opened it, as a small picture-in-picture tile. Ten agent sessions mean ten browsers, each on its own card, and you still know at a glance which one belongs to whom.

The tile has a pill that switches how much room it gets:

Mode	What you get
PiP	a tile at the card’s top right. On the Mac it is the live browser: click, type and scroll in it, and drag its corner to resize it. On the iPhone it is a light preview; tap it and the page opens full screen
Dock Right / Dock Bottom	the browser as its own card beside the agent’s output, fully interactive
Full	the browser fills the session card

The same menu has Open as its own card. The globe in the card’s action pill hides the browser and brings it back.

The mode is yours, per device: your Mac can sit in Dock Right while your phone keeps the same browser as a tile. Offsite suggests the edge that fits the card’s shape (wide cards dock right, tall cards dock bottom), and if a card gets too small for the docked layout, the tile takes over until there is room again.

Shrink the card further and the browser becomes a small globe badge that pulses while the agent is working, with no stream behind it. On the iPhone the tile sends a couple of frames a second and only when the picture changes; the full stream runs once you open the page.

The browser docks to its agent's card as a tile, beside or below the output, or across the whole card, and becomes a pulsing badge on a small card.

An agent’s browser follows its agent. End the session and its docked browser ends with it, profile included. Move the session to the Icebox and the browser stops but keeps its profile, ready when you come back. Detach the browser into a free board card from the same pill, and it outlives the session.

offsite web open --detached (or web_open(detached: true)) creates that free card straight away, for the case where you want a browser that is not tied to one agent.

What the agent can do with it

The verbs reach the agent as tools, from Offsite’s own MCP server, so an agent that supports MCP has them directly, without a wrapper or a sandbox exception:

Tool	What it does
`web_open`	open a URL in a card next to the agent’s own
`web_snapshot`	the page as text — the accessibility tree, one line per element, with refs like `[e12]`
`web_click`, `web_fill`, `web_select`, `web_type`, `web_press`	work the page by ref, CSS selector or coordinates
`web_screenshot`	a PNG, when only pixels answer the question
`web_goto`, `web_back`, `web_forward`, `web_reload`, `web_url`	navigation
`web_eval`, `web_wait`	run JavaScript, wait for load or for a selector
`web_viewport`, `web_settings`	switch device, quality, frame rate, cursor
`web_close`	end the card and its browser

web_snapshot is the one that matters most: a text tree with stable refs is far cheaper and far more reliable than asking a model to find a button in a screenshot. Screenshots are for the questions only pixels answer.

The same verbs exist as a command, for agents without MCP and for you:

offsite web open http://localhost:3000
offsite web snapshot
offsite web click e12
offsite web fill e3 "ada@example.com"
offsite web screenshot --full

Cards belong to a workspace, so an agent can only reach the Agent Browsers in its own.

Using it yourself

You do not have to wait for an agent: add an Agent Browser card yourself and it opens at once, with no dialog, on a start page that lists the web servers running in the workspace; click one to open it. Addresses are resolved on the host, so http://localhost:3000 means the host’s own port 3000, with no tunnel and no exposed port involved. A card you made this way belongs to no agent, and any agent in that workspace can drive it.

Whatever you see in the card, you can also mark: the Mark area button captures the page, opens the annotation editor, and hands the marked picture plus your notes to an agent session, on the same path the Browser card uses.

The card is the agent’s screen, so it has no address bar: the agent navigates. On the Mac, Settings and Mark area float over the page at its bottom right. On the iPhone, the page opened full screen has Open in my browser, Open as its own card, Settings and Close Browser at the top, and a keyboard button for typing into the page next to Mark.

The settings open these controls:

Setting	Options	Why you would touch it
Page (Mac)	Screenshot, Open in my browser	send the whole page to an agent, or open it in your own browser through the host’s tunnel
Screen	Back to responsive, shown while the agent has set a device	return to a page that follows the card
Quality	HD, Balanced, Fast	Fast halves the resolution — the real lever over a slow link
Frame rate	10, 24, 30, 60 fps	lower costs less bandwidth on a remote host
Agent cursor	on / off	show or hide the pointer and click ripple

If nothing is listening on the URL yet, the card says so and offers a retry instead of showing you a stale page from an hour ago.

Agent Browser or Browser?

Two browser cards, two different jobs.

	Browser	Agent Browser
Whose browser it is	yours	the agent’s — you are welcome in it
Runs on	the device in your hand	the host
Reaches the dev server via	a tunnel over your existing connection	nothing — it is on the same machine
Cookies and logins	per device, yours	one profile on the host, shared by your devices
Your personal accounts	yes, this is where they belong	none
After a reconnect	reloads the page	the page is still there, scrolled where you left it
Device emulation	no	a catalog of phones and tablets
Agent access	never	full, through the web tools

Use the Browser for documentation, a deployed site, anything you are personally logged into. Use the Agent Browser for the app you are building, and let the agent have that one instead of anything of yours.

What it needs

On a Mac or an x86-64 Linux host, nothing extra: the host installs its own browser for the Agent Browser and keeps it current with every update. A fresh Linux VPS may need Chrome’s system libraries once, and the card names the exact apt-get line. On an ARM Linux host the Agent Browser uses an installed Chromium, Google Chrome, Brave or Microsoft Edge, and the card names the install command for that machine.
Browser Use in Host Settings, which is on by default. It is the switch that decides whether agents get the web tools at all, and it can stay on because this browser holds none of your personal logins.

Each card owns its browser and its profile: a card is a clean session that starts where you point it and ends when you close it, so an agent always works in a known state. Give a second page its own card.

Both apps need to be reasonably current: the card itself needs protocol 24, the docked browser needs 25. An older client does not show what it cannot render, rather than showing something broken.

Details

The host runs the browser with --headless=new and its own user data directory under the host’s state directory, and talks to it over the Chrome DevTools Protocol. The browser is Google’s Chrome for Testing, unmodified and checked against its hash, pulled with the host as the chrome_runtime component; it has its own app identity, so it never collides with your own Chrome. On a host without that component, discovery takes the first installed Google Chrome, Chromium, Brave or Microsoft Edge. OFFSITE_AGENT_BROWSER_BROWSER points at a specific binary and wins over both.
The picture is a JPEG screencast on the same channel the Simulator card uses; input travels back over a separate socket. Chromium only sends a frame when something changed, so an idle page costs nothing.
Responsive means the client reports the card’s real size in CSS points plus its pixel ratio, and the host applies that as the device metrics, so the page reflows the way a browser window does rather than zooming.
The agent cursor and the click ripple are injected into the page for the stream only. They are marked aria-hidden and are not part of your app.
Refs from web_snapshot stay valid until the next navigation or snapshot.
On the iPhone, the tile and the opened page are two different streams: a scaled screenshot at about two frames a second that only sends when the picture changed, and the full screencast at the quality you picked. On the Mac the tile runs the full screencast.
The dock mode is stored per device, not on the host, so it never travels to someone else’s screen.
Every action is written to the host’s runtime log for that card.