OpenClaw connecting to Browserless - separate "workspace" for separate agents | Friends of the Crustacean 🦞🤝 | Page 1

wet ruin Apr 12, 2026, 5:59 PM

#

@restive oar , I basically don't know what I am doing... trying to set up my first browserless connection for my agent.

What I plan on doing is this - I will eventually have several agents, each of them tapping into browserless with their OWN environment, and my envrionment I mean persistent cookies, etc. I want to be able to see these same "enviornments" so I can do logins on websites before my agents take over etc. But each agent has their own "save data" for cookies etc.

I now have this:

  "browser": {
    "enabled": true,
    "defaultProfile": "browserless",
    "remoteCdpTimeoutMs": 2000,
    "remoteCdpHandshakeTimeoutMs": 4000,
    "profiles": {
      "browserless" {
        "cdpUrl": "ws://localhost:3000",
        "color": "#00AA00"
      }
    }
  }

I don't think it is sufficient for "segregation" of agents?

Also, I want my OpenClaw to get Browserless to NOT use the --disable-dev-shm-usage flag when opening chromium instances. But the container Browserless seems stubborn to include this flag. Any pointers there too?

young notchBOT Apr 12, 2026, 5:59 PM

#

wet ruin Apr 12, 2026, 6:03 PM

#

hello @restive oar ! I need your help ! you are the best !

restive oarBOT Apr 12, 2026, 6:05 PM

#

First, can you paste openclaw --version? Browser/CDP behavior has moved around a bit between releases.

Short version, you’re close, but no, that single profile is not enough for segregation.

A few important bits:

Your snippet has a small JSON5 typo, it should be "browserless": {, not "browserless" {
browser.defaultProfile is global, not per-agent
One OpenClaw browser profile = one named browser target
If multiple agents all use that same browserless profile/URL, they’ll share that target/state unless Browserless itself is giving each one a separate persistent session

So for the setup you want, the pattern is:

Create one OpenClaw profile per agent
Point each profile at a different Browserless persistent session / user-data-dir / reconnect target
Make each agent explicitly use its own profile

#

Something more like:

{
  browser: {
    enabled: true,
    remoteCdpTimeoutMs: 2000,
    remoteCdpHandshakeTimeoutMs: 4000,
    defaultProfile: "agent-a",
    profiles: {
      "agent-a": {
        cdpUrl: "wss://...browserless-session-for-agent-a...",
        color: "#00AA00",
      },
      "agent-b": {
        cdpUrl: "wss://...browserless-session-for-agent-b...",

#

        color: "#0066CC",
      },
      "agent-c": {
        cdpUrl: "wss://...browserless-session-for-agent-c...",
        color: "#AA00AA",
      }
    }
  }
}

So the isolation is really:

OpenClaw side: separate named profiles
Browserless side: separate persistent sessions/state

#

OpenClaw won’t invent cookie isolation if all roads lead to the same Browserless browser.

Also, on the --disable-dev-shm-usage part: that is almost certainly Browserless-side, not OpenClaw-side, in this setup. OpenClaw is just attaching to remote CDP.

Browserless docs do support removing default args with:

ignoreDefaultArgs: ["--disable-dev-shm-usage"]

So that needs to be passed in Browserless launch options / encoded launch= param, not in OpenClaw config.

Useful docs:

OpenClaw browser docs: https://docs.openclaw.ai/tools/browser#browserless-hosted-remote-cdp
OpenClaw browser config reference: https://docs.openclaw.ai/gateway/configuration-reference#browser
Browserless persisting state: https://docs.browserless.io/baas/session-management/persisting-state
Browserless launch options: https://docs.browserless.io/baas/launch-options

#

One honest recommendation: if your main goal is “I log in manually, then agent continues in that exact environment”, a local OpenClaw-managed browser profile is usually easier than Browserless. Browserless can do it, but only if you lean on their persistence/reconnect model.

If you want, paste:

your openclaw --version
whether this is hosted Browserless or a self-hosted Browserless container
how you plan to map agents to profiles

and I’ll sketch the exact JSON5 for your case.

wet ruin Apr 12, 2026, 6:06 PM

#

node@7a440ac70693:/app$ openclaw --version
OpenClaw 2026.3.28
node@7a440ac70693:/app$

restive oarBOT Apr 12, 2026, 6:07 PM

#

Nice, thanks, 2026.3.28 is recent enough that the current browser docs apply.

Two important gotchas here:

If OpenClaw and Browserless are separate Docker containers, ws://localhost:3000 is probably wrong.
Inside the OpenClaw container, localhost means that same container, not the Browserless one.
You usually want the Docker service/container DNS name instead, like:

cdpUrl: "ws://browserless:3000"

One profile is not segregation.
That config only creates one named remote browser target.
For real separation you want:

agent-a profile

#

agent-b profile
agent-c profile

But that only solves the routing part.

The actual cookie/storage isolation must come from Browserless, meaning each OpenClaw profile needs to point at a different persistent Browserless session/context. If they all land on the same Browserless state, they will still mix.

So the OpenClaw side should look more like:

{
  browser: {
    enabled: true,
    remoteCdpTimeoutMs: 2000,
    remoteCdpHandshakeTimeoutMs: 4000,
    defaultProfile: "agent-a",

#

    profiles: {
      "agent-a": {
        cdpUrl: "ws://browserless:3000?...agent-a-session...",
        color: "#00AA00",
      },
      "agent-b": {
        cdpUrl: "ws://browserless:3000?...agent-b-session...",
        color: "#0066CC",
      },
      "agent-c": {
        cdpUrl: "ws://browserless:3000?...agent-c-session...",
        color: "#AA00AA",
      }
    }
  }

#

A few more specifics:

defaultProfile is global, not per-agent
so if you want each agent to always use its own browser profile, you need either:
- explicit profile selection per agent/tool call, or
- separate gateways/instances for hard separation

On --disable-dev-shm-usage:

in this setup, that is Browserless-side, not OpenClaw-side
OpenClaw is just attaching to the remote CDP endpoint
Browserless docs support removing it with:

#

{
  "ignoreDefaultArgs": ["--disable-dev-shm-usage"]
}

That gets passed in the Browserless launch options, not in OpenClaw’s browser config.

Also, if OpenClaw starts complaining that the remote CDP host is blocked/unreachable, and you’re using a Docker-internal hostname like browserless, you may need to allowlist it in both:

browser.ssrfPolicy.allowedHostnames
browser.ssrfPolicy.hostnameAllowlist

Docs:

OpenClaw browser docs: https://docs.openclaw.ai/tools/browser#browserless-hosted-remote-cdp
Browser config reference: https://docs.openclaw.ai/gateway/configuration-reference#browser

#

Browserless launch options: https://docs.browserless.io/baas/launch-options
Browserless persisting state: https://docs.browserless.io/baas/session-management/persisting-state

If you paste your docker-compose.yml, I can translate this into an exact working config instead of hand-wavy pseudo-JSON.

wet ruin Apr 12, 2026, 6:08 PM

#

my two containers share the same network stack

restive oarBOT Apr 12, 2026, 6:08 PM

#

Ah, perfect, then localhost can be fine here.

If the two containers really share the same network namespace/stack, then my earlier “use the service name instead” warning does not apply. That warning is for the more common “same Docker network, separate stacks” setup.

So in your case:

ws://localhost:3000 is plausibly correct
the bigger issue is still segregation/persistence, not connectivity

So the important part remains:

one OpenClaw profile per agent
one Browserless persistent state/session per agent
do not point all those profiles at the same Browserless browser state

In other words, this is still not enough for segregation:

#

profiles: {
  browserless: {
    cdpUrl: "ws://localhost:3000",
  }
}

That is just one target.

You’d want something conceptually like:

{
  browser: {
    enabled: true,

#

    remoteCdpTimeoutMs: 2000,
    remoteCdpHandshakeTimeoutMs: 4000,
    profiles: {
      "agent-a": {
        cdpUrl: "ws://localhost:3000?...agent-a-persistent-session...",
        color: "#00AA00",
      },
      "agent-b": {
        cdpUrl: "ws://localhost:3000?...agent-b-persistent-session...",
        color: "#0066CC",
      }
    }
  }
}

#

But the key is: those URLs need to map to different Browserless persisted sessions, not just different names in OpenClaw.

And on the flag question:

if Browserless is the thing launching Chromium, then Browserless is where --disable-dev-shm-usage must be removed
OpenClaw cannot strip that after the fact
Browserless’ launch options are the right lever, using ignoreDefaultArgs: ["--disable-dev-shm-usage"]

So the model is:

OpenClaw = routing to named browser profiles
Browserless = actual browser lifecycle, flags, persistence

If you want, next message paste either:

your Browserless container config, or
the exact Browserless URL/session pattern you’re using

#

and I’ll help map that into the OpenClaw browser.profiles block cleanly.

wet ruin Apr 12, 2026, 6:10 PM

#

But with my stanza in openclaw.json (i added the colon back), I get this.... i am confused.

node@7a440ac70693:/app$ openclaw browser status

🦞 OpenClaw 2026.3.28 (unknown)
   Self-hosted, self-updating, self-aware (just kidding... unless?).

│
◇
GatewayClientRequestError: unknown method: browser.request
node@7a440ac70693:/app$

restive oarBOT Apr 12, 2026, 6:11 PM

#

Yep, this is actually a different problem, and it happens before Browserless even matters.

unknown method: browser.request means the Gateway did not register the browser plugin/service at all.

So right now, OpenClaw is not even reaching your browserless profile yet.

Most likely causes:

Gateway needs a restart
Browser config/plugin changes need a real Gateway restart.

openclaw gateway restart
openclaw browser status

plugins.allow is set and does not include browser

#

This is a very common gotcha.

Example fix:

{
  plugins: {
    allow: ["browser", "discord"]
  },
  browser: {
    enabled: true
  }
}

Browser plugin was explicitly disabled

#

{
  plugins: {
    entries: {
      browser: {
        enabled: true
      }
    }
  }
}

So the checklist is:

browser.enabled: true
if plugins.allow exists, it must include "browser"
plugins.entries.browser.enabled must not be false

#

then restart the Gateway

This part of the docs is the relevant one:

Browser docs, “Missing browser command or tool”: https://docs.openclaw.ai/tools/browser#missing-browser-command-or-tool

If you want, paste these two parts from your openclaw.json:

plugins
browser

That should be enough to spot it fast.

wet ruin Apr 12, 2026, 6:21 PM

#

ok... thanks for that, now I get this:

node@7a440ac70693:/app$ openclaw browser status

🦞 OpenClaw 2026.3.28 (unknown) — Give me a workspace and I'll give you fewer tabs, fewer togg

│
◇
profile: browserless
enabled: true
running: false
transport: cdp
cdpPort: 3000
cdpUrl: ws://localhost:3000
browser: unknown
detectedBrowser: unknown
detectedPath: auto
profileColor: #00AA00
node@7a440ac70693:/app$

My immediate goal is to see if I can actually establish a connection with browserless (and perhaps open a website) then I will leave it at that. Can you suggest what I should do?

restive oarBOT Apr 12, 2026, 6:22 PM

#

Yep, this looks much better.

For a remote CDP / Browserless profile, status mostly tells you the profile is wired up.
running: false here does not mean “broken”, it just means OpenClaw is not currently attached to an active browser session.

For your immediate smoke test, I’d do exactly this:

openclaw browser --timeout 30000 --browser-profile browserless open https://example.com
openclaw browser --timeout 30000 --browser-profile browserless tabs
openclaw browser --timeout 30000 --browser-profile browserless snapshot

What you want to see:

open succeeds without a websocket/CDP error
tabs shows at least one target

#

snapshot returns page content / refs

If that works, then congratulations, the Browserless connection is basically alive 🎉

A couple of notes:

Do not use start as the proof test here. For remote CDP profiles, open / tabs / snapshot are the better tests.
If open fails, paste the exact error. That will tell us whether it is:
- CDP handshake
- Browserless endpoint shape
- auth/token
- Browserless launch/session behavior

If you want, an even smaller first test is just:

#

openclaw browser --timeout 30000 --browser-profile browserless tabs

but open https://example.com is nicer because it forces a real session to happen.

CLI docs, if helpful: https://docs.openclaw.ai/cli/browser

If that first open command errors, send me the full output and I’ll help decode it.

wet ruin Apr 12, 2026, 6:23 PM

#

node@7a440ac70693:/app$ openclaw browser --timeout 30000 --browser-profile browserless open https://www.google.com

🦞 OpenClaw 2026.3.28 (unknown)
   Welcome to the command line: where dreams compile and confidence segfaults.

│
◇
GatewayClientRequestError: PortInUseError: Port 3000 is already in use.
node@7a440ac70693:/app$

restive oarBOT Apr 12, 2026, 6:24 PM

#

Ah, that’s actually a useful clue, we’re close.

PortInUseError: Port 3000 is already in use means OpenClaw is still trying to treat port 3000 like a locally managed browser port, instead of just attaching to the already-running Browserless service.

For this profile, add:

attachOnly: true

So your profile should be:

{
  browser: {
    enabled: true,

#

    defaultProfile: "browserless",
    remoteCdpTimeoutMs: 2000,
    remoteCdpHandshakeTimeoutMs: 4000,
    profiles: {
      browserless: {
        cdpUrl: "ws://localhost:3000",
        attachOnly: true,
        color: "#00AA00",
      },
    },
  },
}

Then do a real Gateway restart:

#

openclaw gateway restart

Then retry:

openclaw browser --timeout 30000 --browser-profile browserless open https://www.google.com

Why this helps:

cdpUrl tells OpenClaw where to connect
attachOnly: true tells OpenClaw do not launch your own browser on that port

Without attachOnly, it’s basically stepping on Browserless and trying to own port 3000 itself.

#

Relevant docs: https://docs.openclaw.ai/tools/browser

If you retry after adding attachOnly: true, paste the next error or success output and I’ll keep going with you.

wet ruin Apr 12, 2026, 6:28 PM

#

node@7a440ac70693:/app$ openclaw browser --timeout 30000 --browser-profile browserless open https://www.google.com

🦞 OpenClaw 2026.3.28 (unknown)
   I've read more man pages than any human should—so you don't have to.

│
◇
GatewayClientRequestError: Browser attachOnly is enabled and profile "browserless" is not running.
node@7a440ac70693:/app$

restive oarBOT Apr 12, 2026, 6:30 PM

#

That new error means OpenClaw still cannot complete the WebSocket handshake to Browserless at that exact URL.

So the next thing I’d check is this:

1) Are you missing the Browserless token in the URL?

With Browserless, the connection URL is often more like:

ws://localhost:3000?token=YOUR_TOKEN

not just:

ws://localhost:3000

#

If your Browserless container has TOKEN=... set, you need that in cdpUrl.

2) This is also where your launch args belong

Browserless lets you pass launch options in the URL too, so your original --disable-dev-shm-usage goal belongs on the Browserless side, for example via launch=.

Conceptually:

ws://localhost:3000?token=YOUR_TOKEN&launch=<urlencoded JSON>

with launch JSON like:

{
  "ignoreDefaultArgs": ["--disable-dev-shm-usage"]

#

So your OpenClaw profile would be more like:

{
  browser: {
    enabled: true,
    defaultProfile: "browserless",
    profiles: {
      browserless: {
        cdpUrl: "ws://localhost:3000?token=YOUR_TOKEN&launch=%7B%22ignoreDefaultArgs%22%3A%5B%22--disable-dev-shm-usage%22%5D%7D",
        attachOnly: true,
        color: "#00AA00",

#

      },
    },
  },
}

If auth is disabled in Browserless, omit ?token=..., but the current error strongly suggests the endpoint OpenClaw is probing is not accepting that raw anonymous WS connection.

3) Then restart and retry

openclaw gateway restart
openclaw browser --timeout 30000 --browser-profile browserless open https://www.google.com

Useful Browserless docs:

#

Connection URLs: https://docs.browserless.io/overview/connection-urls
Launch options: https://docs.browserless.io/baas/launch-options

If you want, paste just these two things next:

your Browserless Docker image name
whether you set TOKEN=... in the Browserless container

That should be enough to tell whether the URL shape is wrong or auth is missing.

wet ruin Apr 12, 2026, 6:34 PM

#

i can actually do a curl... can you suggest what to do to check for connectivity? and no there is no token

restive oarBOT Apr 12, 2026, 6:34 PM

#

Yep, absolutely. Since curl against raw WebSockets is annoying, I’d test the HTTP face of Browserless first.

Try these from the same container where OpenClaw is running:

curl -i http://localhost:3000/
curl -i http://localhost:3000/json/version
curl -i http://localhost:3000/json/list
curl -i http://localhost:3000/sessions

What I’m looking for:

http://localhost:3000/
- proves the service is reachable at all
http://localhost:3000/json/version
- best case: returns JSON with something like webSocketDebuggerUrl

#

http://localhost:3000/json/list
- often returns JSON array, even if empty
http://localhost:3000/sessions
- Browserless-specific sanity check, often useful for seeing active sessions

If `/json/version` works

Then I would actually try changing OpenClaw to:

cdpUrl: "http://localhost:3000"

instead of:

cdpUrl: "ws://localhost:3000"

#

and keep:

attachOnly: true

Then restart Gateway and retry.

Reason: on loopback/self-hosted Browserless, the HTTP discovery path may be a better fit for OpenClaw than the raw WS URL.

If `/json/version` fails or 404s

Then OpenClaw probably is not talking to the endpoint shape it expects, and we’ll want to see:

the curl outputs
your Browserless image name / version

So yeah, I’d do those 4 curls and paste the outputs here. That should narrow it down fast.

wet ruin Apr 12, 2026, 7:17 PM

#

I traced the logs in Browserless. There was definitely activity going on while doing that "openclaw browser open" thingy:

  browserless.io:server:trace Handling inbound WebSocket request on "/" +34m
  browserless.io:server:trace Found matching WebSocket route handler "/chromium?(/),?(/)" +1ms
  browserless.io:server:trace Authorizing WebSocket request to "http://0.0.0.0:3000/" +0ms
  browserless.io:server:trace Validating route query-params with QUERY schema +0ms
  browserless.io:limiter:debug (Running: 0, Pending: 0) Adding to queue, max time allowed is 300,000ms  +34m
  browserless.io:limiter:debug (Running: 1, Pending: 0) Starting new job  +1ms
  browserless.io:ChromiumCDPWebSocketRoute:info [127.0.0.1] [GET /] Starting new ChromiumCDP instance +0ms
  browserless.io:ChromiumCDPWebSocketRoute:info [127.0.0.1] [GET /] ChromiumCDP got open port 42060 +1ms
    '--disable-features=LocalNetworkAccessChecks',
    '--user-data-dir=/user_data/browserless-data-dir-21beed9b-5525-45b9-a738-34fcd8444c73'
  ],
  executablePath: '/usr/local/bin/playwright-browsers/chromium-1217/chrome-linux64/chrome'
} Launching ChromiumCDP Handler +0ms
  browserless.io:index:info Current period usage: {"date":1776021297759,"error":0,"maxConcurrent":1,"maxTime":null,"meanTime":0,"minTime":null,"rejected":0,"successful":0,"timedout":0,"totalTime":0,"units":0} +5m
  browserless.io:index:info Saving metrics to "/tmp/browserless-metrics.json" +0ms
  browserless.io:ChromiumCDPWebSocketRoute:info [127.0.0.1] [GET /] ChromiumCDP is running on ws://127.0.0.1:42060/devtools/browser/5a9cdca5-531f-4ada-b59d-d383d750cf27 +16s
  browserless.io:router:trace Running found WebSocket handler. +35m
  browserless.io:ChromiumCDPWebSocketRoute:info [127.0.0.1] [sessionId=5a9cdca5-531f-4ada-b59d-d383d750cf27] [GET /] Proxying http://0.0.0.0:3000/ to ChromiumCDP ws://127.0.0.1:42060/devtools/browser/5a9cdca5-531f-4ada-b59d-d383d750cf27 +1ms

restive oarBOT Apr 12, 2026, 7:18 PM

#

Oh, this is actually really helpful.

Those logs say OpenClaw is reaching Browserless, and Browserless is launching Chromium for the connection. So the path is basically right.

The real problem is this part:

Browserless only reports the Chromium CDP target as ready after ~16 seconds
your current config is:
- remoteCdpTimeoutMs: 2000
- remoteCdpHandshakeTimeoutMs: 4000

So OpenClaw is almost certainly giving up way too early.

What I would change next

1) Increase the timeouts a lot

Try something like:

#

{
  browser: {
    enabled: true,
    defaultProfile: "browserless",
    remoteCdpTimeoutMs: 20000,
    remoteCdpHandshakeTimeoutMs: 30000,
    profiles: {
      browserless: {
        cdpUrl: "ws://YOUR_NON_LOOPBACK_IP:3000",
        attachOnly: true,
        color: "#00AA00",
      },
    },
  },
}

#

2) Do not use `localhost` if you can avoid it

This is the sneaky part.

Because localhost is loopback, OpenClaw tends to treat it like a local browser target, not a true remote CDP provider. Your Browserless setup behaves more like a remote broker that takes time to spin up a browser.

So, if possible, use the container/network namespace’s actual IP or hostname, not localhost.

For example, find it with something like:

hostname -i

Then use that IP in cdpUrl, for example:

#

cdpUrl: "ws://172.18.0.12:3000"

Do not use 0.0.0.0 as the client URL, use the real IP/hostname.

Why I think this is the fix

Your logs show:

incoming WS request hits Browserless
Browserless starts ChromiumCDP
it only becomes ready 16 seconds later

So the connection is not fundamentally broken, it’s just not ready fast enough for the way OpenClaw is currently probing it.

Then retry

#

After editing config:

openclaw gateway restart
openclaw browser --timeout 60000 --browser-profile browserless open https://www.google.com

If you hit a private-network / SSRF complaint after switching off localhost, paste that error too, because that’s a separate fix.

Docs: https://docs.openclaw.ai/tools/browser

Honestly, I’m pretty optimistic now, the logs show you’re not far off.

wet ruin Apr 12, 2026, 7:21 PM

#

i have 127.0.0.1 which obviously isn't the right one. both my openclaw and browserless are network-attached to the container with IP = 172.20.0.2 (fixed). So.... use that instead?

restive oarBOT Apr 12, 2026, 7:21 PM

#

Yes, I would try 172.20.0.2 next. That’s the right idea.

Use that instead of localhost, because it should make OpenClaw treat Browserless as a remote CDP target, which is much closer to what Browserless actually is here.

I’d try this config:

{
  browser: {
    enabled: true,
    defaultProfile: "browserless",
    remoteCdpTimeoutMs: 20000,
    remoteCdpHandshakeTimeoutMs: 30000,
    profiles: {
      browserless: {
        cdpUrl: "ws://172.20.0.2:3000",

#

        attachOnly: true,
        color: "#00AA00",
      },
    },
  },
}

Then:

openclaw gateway restart
openclaw browser --timeout 60000 --browser-profile browserless open https://www.google.com

A couple of important notes:

#

use 172.20.0.2, not 0.0.0.0
keep attachOnly: true
keep the larger timeouts, your logs showed Browserless needed ~16s to get the CDP target ready

If OpenClaw then complains about private network / SSRF, that’s a separate issue and we can fix it next. But yes, from what you’ve shown, 172.20.0.2 is exactly what I’d test now.

wet ruin Apr 12, 2026, 7:25 PM

#

so... this?

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

still need attachOnly?

restive oarBOT Apr 12, 2026, 7:25 PM

#

Yep, that’s basically the shape I’d try.

And on your question: attachOnly is not strictly required once you use a non-loopback remote CDP URL, but I’d still keep it. It makes your intent explicit: “OpenClaw, do not launch your own browser here, just connect.”

So:

using 172.20.0.2: yes
bigger timeouts: yes
keeping attachOnly: true: yes, I would

One suggestion though: for debugging, I’d do this in two steps.

Step 1: prove plain connectivity first

Start with:

#

{
  browser: {
    enabled: true,
    defaultProfile: "browserless",
    remoteCdpTimeoutMs: 20000,
    remoteCdpHandshakeTimeoutMs: 30000,
    profiles: {
      browserless: {
        cdpUrl: "ws://172.20.0.2:3000",
        attachOnly: true,
        color: "#00AA00",
      }
    }
  }
}

#

Then restart and test:

openclaw gateway restart
openclaw browser --timeout 60000 --browser-profile browserless open https://www.google.com

Step 2: only after that works, add the `launch=` override

That way you’re not debugging connectivity and Browserless launch args at the same time.

So yes, your final version is reasonable, but I’d personally get this working first:

cdpUrl: "ws://172.20.0.2:3000"

Then later switch to:

#

cdpUrl: "ws://172.20.0.2:3000?launch=%7B%22ignoreDefaultArgs%22%3A%5B%22--disable-dev-shm-usage%22%5D%7D"

If the next error is about private network / SSRF, that’s actually expected-ish with 172.20.0.2, and we can fix that next.

wet ruin Apr 12, 2026, 7:33 PM

#

bingo. that ignoreDefaultArgs seems to have worked too

restive oarBOT Apr 12, 2026, 7:33 PM

#

Hell yes, nice 🎉

So the winning pieces were basically:

use the non-loopback IP
raise the CDP timeouts
pass Browserless launch options via launch=...
ignoreDefaultArgs for the --disable-dev-shm-usage bit

For your original segregation goal, the next step is:

one OpenClaw browser profile per agent
each pointing at its own Browserless persisted session/state
not all agents sharing the same Browserless URL/context

When you’re ready for that part, I can help sketch the multi-profile JSON5 cleanly.

#

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

wet ruin Apr 12, 2026, 7:33 PM

#

node@7a440ac70693:/app$ openclaw browser --timeout 30000 --browser-profile browserless open https://www.google.com

🦞 OpenClaw 2026.3.28 (unknown) — I can't fix your code taste, but I can fix your build and your backlog.

│
◇
opened: https://www.google.com/
id: 6588D478AED361203E583F09E1C70523
node@7a440ac70693:/app$

restive oarBOT Apr 12, 2026, 7:33 PM

#

Beautiful, that’s a real success signal 🎉

That proves:

OpenClaw can reach Browserless
the CDP handshake is working
Browserless is launching the browser correctly
your profile config is now basically valid

You’re officially past the “is this even connected?” stage.

If you want one tiny follow-up sanity check, run:

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

#

And for your original multi-agent goal, the next move is:

clone this into one browser profile per agent
make each one point at a different persisted Browserless state/session

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

wet ruin Apr 12, 2026, 7:38 PM

#

should i try with attachOnly removed? does it even make a difference?

restive oarBOT Apr 12, 2026, 7:39 PM

#

I wouldn’t bother removing it right now.

At this point, with a non-loopback remote CDP URL, attachOnly mostly serves as:

clear intent
a small safety rail so OpenClaw does not try to manage/spawn its own browser there

So:

on localhost, it mattered more
on ws://172.20.0.2:3000, it probably won’t change much
but I’d still leave it in, because it matches what Browserless is: an externally managed browser service

So my recommendation is:

keep attachOnly: true

#

You can absolutely experiment later, but I wouldn’t change a working config just to find out 😄

wet ruin Apr 12, 2026, 7:40 PM

#

finally i am done experimenting for now. the browser session is still active, does openclaw need to tell browserless to close everything?

restive oarBOT Apr 12, 2026, 7:41 PM

#

You don’t have to, but I would. It’s good cleanup.

For a remote/attach-only profile, this is the right command:

openclaw browser --browser-profile browserless stop

That tells OpenClaw to close its active control session. With Browserless, that will usually let Browserless tear the session down too.

So the short version is:

yes, clean it up
use openclaw browser --browser-profile browserless stop

If you want to double-check after:

#

openclaw browser --browser-profile browserless status

and/or watch the Browserless side to see the session disappear.

#OpenClaw connecting to Browserless - separate "workspace" for separate agents