Agent browser
A browser each session drives and you can watch — take the wheel to sign in, hand over logins you already have, and let the agent carry on.
An agent that can write the page can't see it. The agent browser closes that gap: a real browser the session drives, rendered on the canvas so you can watch what it's doing — and grab the wheel when it gets stuck.
Turning it on
Open a session's gear menu and switch on Connect to browser. The session restarts, because an agent binds its tools when its process starts and there's no way to hand one over mid-flight. Anything already in the transcript is kept.
The switch is on Claude Code sessions only. Codex sessions don't show it rather than showing a dead one — the browser reaches the agent as an MCP server, and that's wired through Claude's own configuration.
The first session to use it on a given machine needs a browser to drive. Foreman offers a one-click install and reports its progress on the node; it's a headless Chromium of about 95 MB, kept in Playwright's own cache, so if you already run Playwright tests you have it for free.
Watching it work
The browser appears as a node on the canvas, tethered to the session driving it. What you see is what the page looks like right now, streamed frame by frame.
The stream follows your attention rather than running flat out. Collapse the node to its title bar, or pan it off screen, and the frames stop — the browser stays alive and the agent keeps working, so nothing is lost by not watching. The tether between session and browser lights up when the agent reaches for it, which is usually how you notice something is happening in there.
Each session gets its own isolated browser. Two agents working on the same site do not share cookies, a profile or a page, so one signing out doesn't sign the other out.
Taking the wheel
Click, scroll and type into the node and the input goes through to the real page.
This is the feature's whole reason for existing. An agent that reaches a login form is finished — it has no credentials and shouldn't be given any. Sign in yourself, and it carries on from the page you left it on. You and the agent are both driving the same browser, which is deliberate and works about as well as two people at one keyboard: fine when you're taking turns, confusing if you both grab it at once.
Passing on a login you already have
If you've signed into a site in a Foreman preview, the key button on the node hands those cookies and stored logins to the agent's browser, so you don't type the same password twice.
Two things worth knowing about it:
- The tooltip names the origins it adopted, port included. Cookies ignore the port and browser storage doesn't, so a dev server that moved from
:5173to:5174carries half a login across — which looks exactly like a broken one until you know to look. - If the session runs on a different machine, this copies credentials onto that machine. You're asked about it once, and the answer is remembered.
What the agent can do with it
The agent gets the standard Playwright tool set pointed at that browser: navigate, click, fill, read the page, take a screenshot. Nothing custom, so an agent that has used Playwright knows this already.
Its snapshots and screenshots are written to a per-session directory under /tmp, deliberately outside your repository — the default would litter the working tree, and an agent running git add -A would commit it.
Limits
Free runs one agent browser at a time; Pro runs one per session, which is the part that isn't reproducible by hand — a Chromium profile is single-instance, so several agents each driving their own browser is exactly what adding a Playwright server to your CLI config can't do. The cap only ever blocks opening a new browser: turning one off, or reopening one a session already has, is never gated.
There is no headed mode. The canvas node is the window, and a second visible browser floating over your desktop would only ever be a confusing one.