browser.profiles.[].driver = what is it? | Friends of the Crustacean 🦞🤝 | Page 1

hushed moat Apr 14, 2026, 12:18 PM

#

I am so lost after reading through https://docs.openclaw.ai/tools/browser. So what does "driver" do?
And let me ask in another way - to smoothly connect to Browserless running in a local network location, how should I configure browser?

  "browser": {
    "enabled": true,
    "remoteCdpTimeoutMs": 20000,
    "remoteCdpHandshakeTimeoutMs": 30000,
    "defaultProfile": "openclaw",
    "headless": false,
    "noSandbox": true,
    "attachOnly": true,
    "profiles": {
      "openclaw": {
        "cdpUrl": "ws://172.20.0.2:3000?launch=%7B%22ignoreDefaultArgs%22%3A%5B%22--disable-dev-shm-usage%22%5D%7D",
        "color": "#00AA00"
      }
    }
  },

is this any good? I haven't even included "driver" anywhere.... what about "SSRF policy"? What even is that?

late lintelBOT Apr 14, 2026, 12:18 PM

#

warped oasisBOT Apr 14, 2026, 12:18 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

late lintelBOT Apr 14, 2026, 12:18 PM

#

clever egretBOT Apr 14, 2026, 12:20 PM

#

Short version, driver chooses how OpenClaw talks to the browser.

For your case:

Browserless / remote CDP → use cdpUrl
Do not set driver
driver: "existing-session" is only for attaching to a local signed-in Chrome/Brave/Edge session via Chrome MCP
existing-session is not the Browserless mode, and it should not be combined with cdpUrl

So yes, for Browserless on your LAN, omitting driver is correct.

Your config is close, but I’d simplify it to this:

{
  browser: {

#

    enabled: true,
    defaultProfile: "browserless",
    remoteCdpTimeoutMs: 2000,
    remoteCdpHandshakeTimeoutMs: 4000,
    profiles: {
      browserless: {
        cdpUrl: "ws://172.20.0.2:3000?launch=%7B%22ignoreDefaultArgs%22%3A%5B%22--disable-dev-shm-usage%22%5D%7D",
        color: "#00AA00",
      },
    },
  },
}

A few notes:

#

headless, noSandbox, and top-level attachOnly mainly matter when OpenClaw launches its own local browser.
For a remote Browserless CDP target, they’re usually irrelevant.
I’d rename the profile from openclaw to browserless or remote, just to avoid confusion, because openclaw usually means the local managed browser.

SSRF policy is just a safety guard so the agent/browser can’t be tricked into reaching internal/private network targets unexpectedly.

In plain English:

default behavior right now is basically trusted network mode
so if you do not set browser.ssrfPolicy, your private LAN target like 172.20.0.2 should be allowed
if you later set strict mode with:
```
ssrfPolicy: {
  dangerouslyAllowPrivateNetwork: false
}
```
then private/LAN targets like 172.20.0.2 can get blocked unless explicitly allowed

#

So for your setup, you probably do not need to touch SSRF policy at all unless you want stricter hardening.

Docs I checked:

If you want, I can give you:

a minimal known-good Browserless-on-LAN config, and
the exact openclaw browser ... test commands to verify it end to end.

hushed moat Apr 14, 2026, 12:24 PM

#

a minimal known-good Browserless-on-LAN config would be nice. Also, what is browser UI? Do I get to use it for my situation, and be able to look real time at a website being controlled by OpenClaw?

clever egretBOT Apr 14, 2026, 12:25 PM

#

Yep, here’s the minimal shape I’d use for Browserless on LAN:

{
  browser: {
    enabled: true,
    defaultProfile: "browserless",
    remoteCdpTimeoutMs: 2000,
    remoteCdpHandshakeTimeoutMs: 4000,
    profiles: {
      browserless: {
        cdpUrl: "ws://172.20.0.2:3000?launch=%7B%22ignoreDefaultArgs%22%3A%5B%22--disable-dev-shm-usage%22%5D%7D",
        color: "#00AA00",
      },
    },
  },

#

A few practical notes:

leave driver unset, that is correct for Browserless
remove top-level headless, noSandbox, and attachOnly, they mostly matter when OpenClaw launches its own local browser
restart the gateway after changing browser config

Quick test commands:

openclaw browser profiles
openclaw browser --browser-profile browserless status
openclaw browser --browser-profile browserless open https://example.com

#

openclaw browser --browser-profile browserless tabs
openclaw browser --browser-profile browserless snapshot

About browser UI:

There are really 2 different things people mean:

OpenClaw-managed visible browser window
This is the local openclaw browser profile, usually with headless: false.
You can literally watch the browser window being controlled in real time.
Remote Browserless CDP connection
OpenClaw is controlling a remote browser over CDP.
In this mode, OpenClaw does not give you a built-in live visual browser window by itself.

#

So for your Browserless-on-LAN setup:

yes, OpenClaw can control the site
yes, you can inspect state via tabs, snapshot, screenshot, etc.
no, OpenClaw does not automatically provide a live mirrored UI of that remote browser

If you want to watch it live, that depends on Browserless itself:

if your Browserless setup exposes a live debugger/VNC/session viewer, you can watch it there
if it is just headless in Docker with CDP only, then there’s no real-time visual window to watch

And SSRF policy, simplest version:

it is a safety rule to stop the browser tool from being tricked into hitting internal/private network stuff
for your LAN IP 172.20.0.2, you usually do not need to set anything
current default is effectively trusted-network mode, so private LAN targets are allowed unless you deliberately switch to strict mode

Docs:

#

If you want, next I can give you the equivalent config using http://172.20.0.2:3000 instead of ws://..., which is sometimes easier to debug.

hushed moat Apr 14, 2026, 12:27 PM

#

what is the difference between http://... and ws://.... ? which one is better?

clever egretBOT Apr 14, 2026, 12:27 PM

#

They do different jobs:

http://... / https://... = “here’s the CDP server base URL”
- OpenClaw first calls /json/version
- then it discovers the real DevTools WebSocket URL
- example: easier to debug with curl
ws://... / wss://... = “here is the actual DevTools WebSocket already”
- OpenClaw connects directly
- no /json/version discovery step

So, which is better?

ws:// is usually simpler/faster if Browserless already gives you the exact WebSocket URL
http:// is usually easier to debug because you can test:

#

  curl http://172.20.0.2:3000/json/version

My rule of thumb:

if Browserless docs give you a WebSocket connect URL, use that
if you’re troubleshooting reachability, start with HTTP if the service exposes it
neither is “more correct”, they’re just two supported entry points

For your setup specifically, your current ws://... URL is totally fine if that’s the Browserless connection URL.

Tiny summary:

want simplest runtime path? use ws://
want easiest debugging? use http://

#

Docs confirm both are supported: https://docs.openclaw.ai/tools/browser

If you want, I can give you the same config both ways so you can pick one and compare.

hushed moat Apr 14, 2026, 12:29 PM

#

what is the browser UI's URL? (assuming i am using OpenClaw-managed browser, which I presume means OpenClaw supplies its own browser instance)

clever egretBOT Apr 14, 2026, 12:29 PM

#

There isn’t a separate browser UI URL for the OpenClaw-managed browser.

If you use the OpenClaw-managed browser:

OpenClaw launches a real Chromium/Chrome/Brave window
that window is the UI

you start it with:

openclaw browser --browser-profile openclaw start

So:

Dashboard / Control UI URL → usually http://127.0.0.1:18789/
browser control service → loopback port derived from gateway, usually 18791
actual managed browser UI → not a web URL, it is the browser window itself

#

A couple important gotchas:

the window appears on the machine where the browser is actually running
if your gateway/node host is on another machine, the browser window appears there, not on your laptop
if headless: true, there is no visible window

So yes, “OpenClaw-managed browser” means OpenClaw supplies and controls its own browser instance/profile, but you do not open it by visiting a special URL.

If you want, I can also explain the 3 different things people mix up here:

Dashboard URL
browser control service port
actual visible managed browser window

hushed moat Apr 14, 2026, 12:31 PM

#

so you type http://127.0.0.1:18791 to access the browser UI? I am not sure I follow you.

clever egretBOT Apr 14, 2026, 12:32 PM

#

No, don’t type http://127.0.0.1:18791 into your browser expecting a browser UI.

That 18791 port is the internal browser control service, not a human-facing page.

The simplest mental model is:

127.0.0.1:18789 = OpenClaw dashboard / Control UI
127.0.0.1:18791 = internal browser control endpoint
browser UI = the actual Chrome/Chromium window that OpenClaw launches

So if you use the OpenClaw-managed browser with headless: false, you do this:

openclaw browser --browser-profile openclaw start

Then a real browser window should open on that machine.

#

That window is the UI.

So:

local machine → you’ll see the browser window pop up
remote server / Docker / headless box → there is no local window for you to look at

If what you want is:

“a web page I can open to watch the agent-controlled browser live”

then OpenClaw itself does not currently give you that for the managed browser.

For that, you’d need something else, like:

Browserless live/session viewer, if your Browserless setup provides one
remote desktop / VNC to the machine running the browser

#

screenshots/snapshots from OpenClaw instead of a live visual feed

So the short answer is:

18791 is not the browser UI URL
the browser UI is the actual launched browser window
there is no built-in live mirror URL from OpenClaw

If you want, I can draw the whole thing as a tiny “ports and windows” diagram, because yeah, this part is confusing.

hushed moat Apr 14, 2026, 12:33 PM

#

the browser UI is the actual launched browser window - so as and when openclaw does the automation, mouse movements, navigation, etc, you will see the popped up Browser UI update itself in real time?

clever egretBOT Apr 14, 2026, 12:34 PM

#

Yes, for the OpenClaw-managed browser with headless: false, you’ll generally see it update in real time:

pages opening
navigation changing
fields getting typed into
clicks taking effect
scrolling
dialogs / page state changes

The one nuance is, it may not always look like a human literally wiggling a mouse around.

A lot of browser automation is done through CDP / Playwright-style commands, so:

you will see the browser/page change
you may not always see a visible mouse cursor travel smoothly from point A to point B

So the best mental model is:

#

yes, you can watch the browser being controlled live
no, don’t expect perfect “screen recording of a human hand on a mouse” behavior

And just to keep the two modes separate:

OpenClaw-managed local browser → yes, visible live window
Browserless remote CDP → usually no local visible window from OpenClaw

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for future users 🎉

#browser.profiles.[].driver = what is it?