Chrome browser

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

Chrome browser control drives the member’s own local Chrome through a browser extension — not the hosted session browser, and not the cloud Preview. It exists for work that only the member’s browser can do: pages behind the member’s logins, local-only addresses, profiles no hosted browser holds. The chrome_browser plugin tools run list → claim → snapshot → actions, one run at a time.

How a run works: list → claim → snapshot → actions

1. List. The session lists local browsers available to claim. Unclaimed and reachable is the only valid starting state — anything else is a setup problem, not a retry loop.
2. Claim. The run claims one browser. The claim is per run: one claimed browser serves one session run, and the claim releases when the run ends.
3. Snapshot. The run snapshots the claimed browser to confirm state: which page is open, what the run sees. Snapshot before acting — an action without a preceding snapshot is guessing.
4. Actions. The run acts on the claimed browser: navigate, read, fill, submit — each step recorded in the transcript. Submits and account changes pause at the approval gate exactly as elsewhere.

What list resolves to in practice — no dedicated multi-tab list UI was available in UAT, so there is no claimed-vs-available browser list to show. What this capture proves instead is the successful chrome_browser observation once a browser is claimed: Observation details carrying the claimed tabId 537866698, followed by a second Observation block with the snapshot nodes (ref e3/e4, paragraph and form roles, shared frameId), above Completed 2 Actions rows and a page-loaded / note-fill transcript.

• The tabId observation is the receipt the claim landed; the snapshot nodes are what the run sees before it acts.
• Read this as the list step’s outcome (one claimed browser, observed and confirmed), not as a browser-picker UI.

Claim then snapshot, including the failure path: the run first reports the Chrome connector unavailable — the extension bridge chrome_browser needs is not connected — and refuses the sandbox headless substitute because it would not validate what was asked. Once the managed Chrome extension reconnects, the run proceeds with Completed 2 Actions rows and Observation details carrying the snapshot: the claimed tabId and the observed nodes.

• Snapshot before acting — an action without a preceding snapshot is guessing; the tabId observation is the receipt the claim landed.
• A disconnect stops the run; reconnect starts a fresh run with a fresh claim and snapshot, never a resumed claim.

Actions on the claimed browser, recorded step by step: once the managed Chrome extension reconnects, the run proceeds with Completed 2 Actions rows — page load, note fill — and Observation details carrying the snapshot (performed: "set_value", the observed tab nodes). No disconnect or reconnect buttons are shown here; the only failure path visible is the transcript itself, where the earlier connector failure stays on record above the completed actions.

• Each action lands in the transcript with its observation — an action with no transcript line did not happen.
• The failure stays visible instead of being rewritten: the run names what it needs (reconnect and re-authorize the extension) rather than improvising around it.

Install

Chrome control arrives as an installed capability with a member-side install path: install the chrome_browser package from the plugin registry, grant it to the agents that need it, and confirm the session environment policy allows it. The Manage modal shows Installed status with its skill (operate permitted local Chrome tabs) and the chrome_browser tool, subject to agent and environment permissions, pointing back to the agent’s Plugins tab to enable it. Then the member connects local Chrome: open preshos.com/browser-extension, add the extension from the Store, and Connect it. Until package install, agent grant, environment policy, and extension connection all hold, the session panel will not list it — see Plugins in session.

Troubleshoot

• Disconnect mid-run: the run reports the disconnect in the transcript and stops acting. Do not re-run actions blind — snapshot first once reconnected, confirm state, then continue from what the transcript proves happened.
• No host or desktop backend: the claim cannot land. This is a scoping question for the tenant admin (host needs a desktop backend; Chrome control requires a host plus desktop), not a wording problem.
• Reconnect means a new run. A reconnected browser starts a fresh run with a fresh claim and snapshot — it never resumes the old run’s claim. Carry context by reading the previous transcript, not by assuming browser state survived.
• Wrong profile or login wall: the claimed browser is the member’s own, so its logins are real. Work that hits an unexpected sign-in waits for the member rather than improvising around it.

Hosted browser vs. local Chrome: do not confuse them

• The hosted session browser (Browser use) is Playwright-driven, inside the sandbox, watched in the Inspector Browser tab. No member device involved.
• Local Chrome via extension (this page) drives the member’s own browser: claim per run, snapshot to verify, reconnect is a new run, needs a host with a desktop backend.
• The cloud Preview is a render surface, not a browser — never describe chrome_browser as cloud Preview, and never describe computer use as VNC. See Computer use.

This page drives the member browser outside the sandbox — claim per run, snapshot to verify, reconnect starts a new run, host with a desktop backend required. The hosted browser stays inside the sandbox under Playwright with the Inspector Browser tab.

What next

• Browser use: the hosted session browser, the narrower default.
• Computer use: full OS-level control when the work leaves any browser.
• Plugins in session: install → grant → session → invoke for the chrome_browser package.
• Sandbox: the isolated space the hosted browser runs inside.
• Approving agent actions: the gate Chrome actions pause at.