Chrome Browser help | Friends of the Crustacean 🦞🤝 | Page 1

analog roost Apr 12, 2026, 11:30 PM

#

I was working with my security bot on trying to configure and setup a headless Chrome browser session that OpenClaw could use and had a very hard time with it. I ended up running in circles with my agent named Scooter and he gave a high level synopsis of what we tried. Any help would be appreciated. Im running on a headless VPS Ubuntu 24.04LTS btw. TIA.

Yep, here’s a short one you can screenshot:

OpenClaw browser question / possible bug

Running OpenClaw 2026.4.11 on Ubuntu VPS
Chrome headless is running fine as a persistent user systemd service on 127.0.0.1:9222
curl http://127.0.0.1:9222/json/version works, so CDP is definitely live
Configured a custom browser profile with cdpUrl: "http://127.0.0.1:9222" and later attachOnly: true
OpenClaw still reports that profile as running: false
openclaw browser --browser-profile remote open ... and snapshot both fail with:
Browser attachOnly is enabled and profile "remote" is not running

Question: is local Chrome exposed via cdpUrl on the same VPS supposed to work as a remote CDP profile, or is this an unsupported / currently broken path?

smoky owlBOT Apr 12, 2026, 11:30 PM

#

cobalt garnetBOT Apr 12, 2026, 11:30 PM

#

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

empty willowBOT Apr 12, 2026, 11:33 PM

#

I’m checking the docs and source for the browser/CDP path now, because this smells like a real edge case rather than user error.

#

Docs do show that raw remote CDP on cdpUrl is supposed to work. I’m verifying the exact failure mode in source so I don’t hand-wave you into another dead end.

#

Yes, that path is supposed to work.

What’s tripping you up is probably this combo:

curl http://127.0.0.1:9222/json/version only proves the HTTP endpoint is up.
OpenClaw also does SSRF checks and then a CDP WebSocket attach.
On 2026.4.11, a cdpUrl on 127.0.0.1 is treated as a loopback/local attach-only profile, not a “remote” one, so the error text can be misleading.

The most likely fix is to explicitly allow loopback CDP in browser.ssrfPolicy, and keep the profile as raw CDP, not existing-session.

{
  browser: {
    enabled: true,
    ssrfPolicy: {
      allowedHostnames: ["127.0.0.1", "localhost"],

#

      hostnameAllowlist: ["127.0.0.1", "localhost"]
      // simpler but broader:
      // dangerouslyAllowPrivateNetwork: true
    },
    profiles: {
      remote: {
        cdpUrl: "http://127.0.0.1:9222",
        attachOnly: true
      }
    }
  }
}

A couple of important bits:

#

do not set driver: "existing-session" for this path
cdpUrl + attachOnly: true is the right shape
after changing config, restart the gateway

Then test:

openclaw gateway restart
openclaw browser profiles
openclaw browser --browser-profile remote tabs
openclaw browser --browser-profile remote snapshot

If it still fails, run this while retrying:

#

openclaw logs --follow

and look for messages like browser endpoint blocked by policy or CDP websocket reachability errors.

Docs:

If you want, paste your browser config block and the relevant openclaw logs --follow lines, and I can sanity check it.

analog roost Apr 13, 2026, 2:31 AM

#

This solved it thanks

empty willowBOT Apr 13, 2026, 2:31 AM

#

Nice, glad that fixed it 🎉

If this solved it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for future folks.

#Chrome Browser help