Browser use

Open in product: preshos.com/agent-ops/browser-use

Browser use gives a session a scoped hosted browser: the agent opens pages, reads what they show, fills forms, and follows multi-page flows, all inside the session boundary. The browser is automation-driven (Playwright by default, hosted Eve runtime), and members watch it through the Inspector’s Browser tab. It is the narrower sibling of computer use — web work only, under the same governance. It is not the member’s Chrome: local-Chrome control through the extension lives on the Chrome browser page.

How the browser works

• The browser belongs to the session, not the member. It opens inside the sandbox under the session’s environment policy — history, cookies, and logins do not leak into personal browsing or other tenants.
• The agent narrates as it goes: which page it opened, what it read, what it is about to submit. That narration is the transcript, and it reads like the rest of the session. The Browser tab in the Inspector shows the same work visually.
• Reads flow; submits pause. Looking at a page is a read. Submitting a form, changing an account, or sending anything on the member’s behalf goes through the approval gate first.

Watching: Inspector Browser tab + transcript trail

Two views of the same work — use both:

• Inspector Browser tab shows the pages as the agent sees them: what is open, what is filled, where the run currently sits. Open it from the session Inspector while the run is live; it is the fastest way to catch a wrong page or a sign-in wall.
• Transcript trail is the record: every page opened, everything read, every submit proposed and its decision. The Browser tab shows now; the transcript proves what happened. An action with no transcript line did not happen here.
• When the two disagree (tab shows a page the transcript never mentions), trust the transcript and report the gap — then continue from the transcript state, not the tab.

The watch surface: a tab strip (Overview, Files, address, Terminal, browser tab) beside the run transcript. The page open here is example.com — a placeholder documentation page, not a dedicated Eve session browser run — shown for the shape of the surface, not as a live session page. The transcript alongside it belongs to a local-Chrome (chrome_browser) run reporting its connector unavailable, borrowed here to show the side-by-side layout rather than a hosted-browser run.

• Open the Browser tab from the session Inspector while the run is live; it mirrors what the agent sees.
• A placeholder page in the tab proves the surface exists, not that the run is working — the transcript is what confirms live state.

The trail, step by step: page loaded, value entered, saved value confirmed, persistence verified after reload, then the screenshot. This particular trail comes from a local-Chrome (chrome_browser) acceptance run — not the hosted session browser — used here to show the narration pattern: every page opened, everything read, every submit proposed. On this page’s hosted browser the same contract holds: the Browser tab shows now, the transcript proves what happened.

• Read the trail as the record: an action with no transcript line did not happen here.
• Reload-and-verify is the pattern to copy: a save the run never re-reads is a claim, not a result.

Screenshots and egress

• Browser screenshots land under /workspace/working/browser/ in the session working tree. They are verification evidence for the run, not the control plane.
• Network egress is open except denied CIDR ranges: the hosted browser reaches the open web, with blocklisted ranges unreachable. A page that never loads is an egress question for the tenant admin, not a wording problem.

Screenshots as evidence: a captured browser frame with its observation payload (viewport dimensions, coordinate space) recorded underneath, then a run recap narrating the full flow. This capture comes from a local-Chrome acceptance run — the saved-note page and its observation JSON illustrate the evidence pattern, not the /workspace/working/browser/ folder itself, which is where this page’s hosted-browser screenshots land for the run record.

• Treat the screenshot plus its observation payload as one unit: the image shows, the payload locates.
• Verification evidence lives with the run; screenshots confirm what the transcript claims.

How to access it

• Ask the session in plain language, as part of a bounded goal: read this page, check this record, fill this form for review.
• Confirm the environment reaches the web the task needs. A session whose environment grants no browser or no network is a scoping question for the tenant admin, not a wording problem.
• Stay in the thread while it works. Browser flows hit sign-in walls, changed layouts, and consent screens — the agent reports them in the transcript and waits rather than improvising around them.

Hosted browser vs. local Chrome

• This page covers the hosted session browser: Playwright-driven, inside the sandbox, watched in the Inspector Browser tab. No member device involved.
• Local Chrome via the extension drives the member’s own browser: claim per run, snapshot to verify, reconnect means a new run, and it needs a host with a desktop backend. Separate surface, separate rules: Chrome browser.
• Never describe one as the other. If the task needs the member’s logged-in profile or local-only pages, that is the Chrome path, not this one.

Hosted browser runs Playwright inside the sandbox and is watched in the Inspector Browser tab — no member device involved. Local Chrome runs on the member device through the extension: claim per run, snapshot to verify, reconnect starts a new run.

What next

• Chrome browser: local-Chrome control when the work needs the member’s browser.
• Computer use: full OS-level control when the work leaves the browser.
• Sandbox: the isolated space the session browser runs inside.
• Approving agent actions: deciding on submits the browser proposes.