The Browser card

Your agent starts a dev server. It listens on localhost on the host, which is a machine you may not be sitting at. Normally that is where remote work stops.

The Browser card forwards that loopback port over the connection you already have and renders the page, on your Mac and on your phone. It is your browser: your cookies, your logins, your session. No agent can see it or touch it.

Using it

Add a Browser card and it opens straight away, on the last URL you used in a browser card. No dialog, no setup step.

The bar across the top is a real browser bar:

Control
Back, forward, reload	⌘[, ⌘], ⌘R — and ⇧⌘R reloads past the cache, for dev servers that serve stale bundles. Esc stops a load
The address field	type a URL, or type words to search. ⌘L focuses it
History	⌘Y; ⌘-click an entry to open it in a new tab. Rows carry the site’s icon
+	a new tab — ⌘T, close with ⌘W, switch with ⌃Tab and ⌃⇧Tab, ⌥⌘→ and ⌥⌘←, or ⇧⌘] and ⇧⌘[ on a US layout; jump with ⌘1 to ⌘8, ⌘9 is the last tab
Camera	send the whole page to an agent — ⇧⌘S
Marquee	mark an area of the page and send that
Wrench	Developer Tools — ⌥⌘I, in their own window

⌘F opens find-in-page. The ports menu next to the address lists what is actually listening on the host for this workspace (:3000 node · Claude), so you can jump to a dev server without remembering its port.

Typing a different loopback port reopens the card on a new tunnel; anything else navigates in place. And when nothing is answering yet, the card says exactly that and offers a retry, instead of turning into a broken card that stays broken after the server comes up.

Shrink the card and it turns into a launchpad: the current page as a cover with its title and an address box, then your tabs, the servers running in the workspace and recent pages, each with the site’s icon. Public pages show the preview image the site publishes for links, the same one messaging apps show; your dev servers show a live capture of the page instead.

Mark what is wrong, hand it to an agent

You are looking at the page the agent just built, and something is off. Instead of describing where it is:

1. Hit the marquee button and drag a rectangle around it, or ⇧⌘S for the whole page.
2. The annotation editor opens: circle things, number them, write one line per number.
3. Pick the target session, an intent (fix, change, question or approve) and add a note.

Offsite uploads the marked image to the host and pastes a block into that session: your notes, the page URL, the CSS selector of the element you marked, its surrounding HTML, and in a dev build of a React app the component and the file:line it came from. Plus a line telling the agent how to open the same page in its own browser.

Nothing is submitted. The text sits in the prompt; you press Enter.

If no agent session is running, the target picker offers to start one.

This one is yours

The Browser renders on your device, with your cookies and your logins, and no agent can reach it — not through a tool, not through the CLI, not by asking. Data moves in one direction only: from you to the agent, when you send it.

The Agent Browser is the opposite: one browser on the host that the agent drives, showing the same page on all your devices. One is yours, the other is the agent’s, and you are welcome to watch.

On iPhone and iPad

The card is Safari, so it behaves like Safari, including your logins and the share sheet. Marking up a page happens in the Agent Browser card: the card menu has Open in Agent Browser, which opens the same URL host-side.

Details

• macOS forwards with ssh -L; iOS opens a direct-tcpip channel natively over its own SSH implementation. Both ride the connection the app already has, so nothing new is authenticated, no port is opened on the host, and the dev server stays private to your own devices.
• Forwarding targets the host’s loopback interface, so a server bound to 127.0.0.1 is enough.
• The macOS card renders in a bundled Chromium (CEF) rather than WKWebView, because third-party sign-in popups do not work reliably in the latter. Screen captures and page JavaScript run through the Chrome DevTools Protocol.
• The browser profile is per workspace and lives on your Mac, not on the host.
• A new card opens on the last URL used in a browser card on this device, else the newest browser session on the host, else the Offsite start page.
• Port discovery scans the host’s socket table every few seconds and maps listeners to sessions through the process tree; servers started outside a session are listed for the workspace instead.
• Stale forwards from a previous run are cleaned up when the Mac app launches.