Brave browser not working correctly | Friends of the Crustacean 🦞🤝 | Page 1

#

Port 18800 listening is only half the story.

OpenClaw does not mark the browser healthy just because Brave bound the TCP port. It then tries:

http://127.0.0.1:18800/json/version
read webSocketDebuggerUrl
open the CDP websocket and run a small Browser.getVersion health check

That exact error means step 3 never became healthy, even though Brave was listening. So running: false is expected here.

First check this directly:

curl -i http://127.0.0.1:18800/json/version
curl -s http://127.0.0.1:18800/json/version | jq .

#

If that JSON is missing webSocketDebuggerUrl, or curl hangs/fails, OpenClaw will fail exactly like this.

Since this is Linux, I’d also try the Linux browser settings from the docs:

{
  browser: {
    executablePath: "/usr/bin/brave-browser",
    headless: true,
    noSandbox: true
  }
}

Then restart the gateway and retry.

Docs:

#

If you want, paste:

the output of curl -s http://127.0.0.1:18800/json/version | jq .
your browser block from ~/.openclaw/openclaw.json

and I can narrow it down pretty fast.

#

Nice, that narrows it a lot.

Your curl /json/version output is good. So:

Brave is launching
CDP HTTP discovery is working
webSocketDebuggerUrl is being published

That means the failure is now specifically the browser websocket command probe, not process launch.

2026.4.11 got stricter here: OpenClaw only considers CDP healthy after it can successfully do Browser.getVersion over the websocket, not just because the port is open or /json/version works. So your symptom matches that exactly.

I’d try this next in ~/.openclaw/openclaw.json:

#

  browser: {
    enabled: true,
    executablePath: "/usr/bin/brave-browser",
    headless: true,
    noSandbox: true
  }
}

Then restart the gateway and retry openclaw browser start.

If that still fails, I’d do the isolation test:

#

  browser: {
    enabled: true,
    executablePath: "/usr/bin/brave-browser",
    headless: true,
    noSandbox: true,
    attachOnly: true
  }
}

Then start Brave manually:

/usr/bin/brave-browser --headless --no-sandbox --disable-gpu \
  --remote-debugging-port=18800 \

#

  --user-data-dir="$HOME/.openclaw/browser/openclaw/user-data" \
  about:blank

Why this helps:

if manual + attachOnly works, the problem is very likely OpenClaw’s launch/readiness timing on this host
if manual + attachOnly still fails, then the browser websocket itself is unhealthy, even though /json/version looks fine

Docs:

If you try those two steps and it still breaks, paste the result, and if it ends up looking like a bug, please file it here with your exact outputs: https://github.com/openclaw/openclaw/issues

#

Edit the top-level browser block, not the one under plugins.

In short:

browser: { ... } = actual browser runtime settings (headless, noSandbox, executablePath, attachOnly, etc.)
plugins.entries.browser: { ... } = only enables/disables the bundled browser plugin itself

So for your case, change this one:

{
  browser: {
    enabled: true,
    executablePath: "/usr/bin/brave-browser",
    headless: true,
    noSandbox: true

#

}
}

Leave plugins.entries.browser alone unless you’re trying to disable/replace the browser plugin.

One extra gotcha: if you have a plugins.allow list, make sure it includes "browser" too.

Docs:

After editing, restart the gateway, then retry openclaw browser start.

If you want, paste the full browser + plugins section and I’ll sanity-check it.

#

Ah, damn, that rules out the easy Linux sandbox fix.

At this point I’d do the attach-only isolation test next. That’s the cleanest way to tell whether the problem is:

OpenClaw’s launch/readiness path, or
Brave’s CDP websocket itself

Use this config:

{
  browser: {
    enabled: true,
    executablePath: "/usr/bin/brave-browser",
    headless: true,
    noSandbox: true,

#

    attachOnly: true
  }
}

Restart the gateway, then start Brave manually:

/usr/bin/brave-browser --headless --no-sandbox --disable-gpu \
  --remote-debugging-port=18800 \
  --user-data-dir="$HOME/.openclaw/browser/openclaw/user-data" \
  about:blank

Then, in a second shell, run:

#

openclaw browser start
openclaw browser status

Why I want this test:

if this works, then Brave/CDP is fine and 2026.4.11 is likely tripping on the managed launch/readiness path on your host
if this still fails, then the browser websocket itself is the bad part, even though /json/version looks healthy

If you just want the fastest path to “working now”, the docs’ Linux recommendation is also to try Google Chrome stable instead of Brave:
https://docs.openclaw.ai/tools/browser-linux-troubleshooting

Try the attach-only/manual-start test first and paste the result. That should tell us which side is broken.

#

Oh, that’s actually a really useful clue.

If Brave prints:

DevTools listening on ws://127.0.0.1:18800/...

then Brave itself is up. So now the problem is: OpenClaw still isn’t accepting/reaching that loopback CDP target.

I’d try making the attach target explicit, and allowlisting loopback on both SSRF keys:

{
  browser: {
    enabled: true,

#

    executablePath: "/usr/bin/brave-browser",
    headless: true,
    noSandbox: true,
    ssrfPolicy: {
      allowedHostnames: ["127.0.0.1", "localhost"],
      hostnameAllowlist: ["127.0.0.1", "localhost"]
    },
    profiles: {
      openclaw: {
        cdpUrl: "http://127.0.0.1:18800",
        attachOnly: true
      }
    }
  }
}

#Brave browser not working correctly