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 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 ship with Offsite and run on the host the agent is already working on.

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. Or pick a device: 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.

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 small view-only tile, cheap to stream, enough to see that something is happening
Dock Right / Dock Bottom	the browser as its own card beside the agent’s output, fully interactive
Full	the browser fills the session card
Hide	nothing, until you bring it back from the card’s action pill

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 when the agent is working. So a board full of agents costs one video stream, not ten: the tile sends a couple of frames a second and only when the picture changes, and the full stream runs for the browser you enlarged.

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, give it a URL and start with Responsive, Desktop or Mobile. The URL is 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 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 carries a slim bar: back, forward, reload, and the address with the page title. On iPhone there is a keyboard button for typing into the page, and an enlarge button when the card is too small to work in.

The settings button opens four controls:

Setting	Options	Why you would touch it
Screen	Responsive, or a device from the catalog	check a phone layout without a phone
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

A Chromium-family browser on the host: Google Chrome, Chromium, Brave or Microsoft Edge. The card names the exact install command for that machine if it has to.
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. Nothing is bundled with Offsite and nothing is downloaded: it uses the browser already installed on that machine. OFFSITE_WEBSIM_BROWSER points at a specific binary if discovery picks the wrong one.
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.
The docked tile and the enlarged browser 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.
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.