Does the browser keep cookies and login state?
Yes. Hosted Browser stores its Chromium profile on the instance volume, so cookies and login state can persist across browser restarts until you reset the profile.
Feature
Give your OpenClaw instance its own persistent browser
Enable a hosted browser sidecar so your OpenClaw agent can use a real Chromium session, while you can open the same browser from the dashboard for auth, MFA, CAPTCHA, and manual takeover.
Hosted Browser turns browser access into part of the managed OpenClaw runtime. The browser runs next to the instance, keeps its profile on the instance volume, exposes CDP only on pod loopback for the agent, and gives the account owner an authenticated KasmVNC viewer from the dashboard.
What you can do
- Enable a persistent Chromium browser from Addons without running Chrome on your laptop.
- Keep cookies, sessions, and profile state on the instance volume across browser restarts.
- Let the OpenClaw agent attach through local CDP instead of a public browser endpoint.
- Open the same browser from the dashboard when a site needs login, MFA, CAPTCHA, or judgment.
- Use the authenticated browser viewer without exposing VNC or CDP directly to the public internet.
- Reset the browser profile from the dashboard when you want a clean session.
OpenClaw with BrowserLaunch announcementArchitecture deep-diveChrome Extension relay
Real product screenshot
Why this is different from a headless-only browser
Headless browser infrastructure is useful, but many real workflows break when auth, MFA, CAPTCHA, file downloads, or human judgment enters the loop. Hosted Browser keeps the browser visible and persistent so the user can step in without moving the workflow to another machine.
The important product shift is that the browser belongs to the OpenClaw instance. It is not a disposable demo tab and it is not only your local Chrome. It is a managed browser session that survives normal restarts and can be shared between the agent and the account owner.
- Persistent browser profile instead of throwaway sessions
- Visible browser takeover from the dashboard
- Local CDP for the agent
- Authenticated viewer access for the account owner
When to use Hosted Browser vs Chrome Extension relay
Use Hosted Browser when you want the instance to own the browser session and keep it available even when your laptop is closed. Use Chrome Extension relay when the agent must work with a tab that is already open in your local desktop browser.
Both options exist because browser workflows split into two practical modes: a cloud browser that follows the hosted agent, and a local relay for the exact browser tab on your machine.
- Hosted Browser: persistent cloud-side browser tied to the instance
- Chrome Extension relay: local user Chrome tab intentionally attached to the hosted agent
- Web fetch/search: faster read-only retrieval when no interactive browser is needed
Security boundary
The OpenClaw agent reaches Chromium through a pod-local CDP URL. The visual browser is opened through the OpenClaw Setup backend auth proxy, and access requires the owning dashboard account.
That means the browser can be useful for real auth-heavy workflows without turning VNC or CDP into a broadly exposed public endpoint.
FAQ
Can the user and agent use the same browser?
Yes. The user opens the browser from the dashboard, while the agent attaches to the same browser sidecar through local CDP inside the instance pod.
Is this the same as the Chrome Extension relay?
No. Hosted Browser is a browser that runs with the hosted instance. Chrome Extension relay connects the hosted agent to a browser tab on your local machine.