OpenClaw's browser: what your agent can do on the web
A real Chromium driven via Playwright, in an isolated profile, on by default. The three profile modes and their trust levels, server setups, and what it won't bypass.
OpenClaw ships a real browser, on by default: a Chromium instance driven through Playwright, running in its own isolated openclaw profile that never touches your personal browsing. Your agent can open pages, click, type, fill forms, take screenshots, and extract structured data. Two opt-in modes can drive your signed-in Chrome instead — that’s where the real trust decision lives.
What the browser tool actually does
The tool is called browser, and the docs describe it as a separate, agent-only browser. It navigates, clicks, types, hovers, selects, fills and submits forms, manages tabs, takes snapshots and screenshots, and runs an extract action that pulls structured data from a page. Under the hood it launches a Chromium-family browser and controls it via Playwright on top of the DevTools protocol. One detail that surprises people: on a desktop it opens a visible window by default — browser.headless defaults to false — so you can literally watch your agent work. On a Linux server with no display it falls back to headless automatically.
Three profiles, three trust levels
Where the browser’s cookies and logins live is the security decision, and OpenClaw gives you three options:
- The
openclawprofile (default): a dedicated user-data directory, fully separate from your own browser. Anything the agent signs into lives there and only there. This is the right default and most people should stay on it. - The
userprofile: attaches to your real, signed-in Chrome via remote debugging (you approve a prompt at attach time). The docs are direct that this is higher-risk than the isolated profile, because the agent can act inside your logged-in accounts. - The Chrome extension: drives your signed-in Chrome too, but with a consent boundary you can see: the agent only touches tabs you drag into a dedicated OpenClaw tab group, and dragging a tab out revokes access instantly.
The docs’ own warning is worth repeating: a browser profile with logged-in sessions is sensitive state — whatever that profile can reach, the model can reach. If the agent needs its own accounts, create them; don’t lend it yours.
Running it on a server
This is where the Docker image variants finally make sense: the -browser tags ship with Chromium baked in, so the browser tool works without a first-run Playwright download; the plain image needs Chromium installed separately (the docs offer an OPENCLAW_INSTALL_BROWSER=1 build-time bake). We run the -browser image on our own pods and have measured what it costs: on a 2 vCPU / 4 GB box, the container idles around 540 MiB and renders pages headlessly without drama — a small VPS genuinely carries it. For the cautious, OpenClaw can also run the browser inside a separate sandbox container on its own Docker network, keeping web pages away from the Gateway’s filesystem entirely.
What it deliberately won’t do
The agent is instructed to hand logins, two-factor prompts, and CAPTCHAs back to you as manual actions — there’s no bypass built in, and the docs claim none. That’s the honest position, because the open web increasingly challenges automated browsers on sight, and an agent that hits a bot wall should say so rather than pretend. Navigation is also SSRF-checked by default: private and internal network addresses stay blocked unless you explicitly opt in — a quiet but important guard when the browser runs on the same machine as other services. And remember that every page the agent reads is untrusted input: OpenClaw’s security docs name browser pages as a prompt injection vector, which is a good reason to keep the browser in its isolated profile and the agent on a machine you don’t mind it owning.