Openclaw browser failing on a fresh install | Friends of the Crustacean 🦞🤝 | Page 1

normal wind Apr 13, 2026, 12:41 PM

#

fhorst@openclaw:~$ openclaw browser status

🦞 OpenClaw 2026.4.11 (769908e) — I don't judge, but your missing API keys are absolutely judging you.

│
◇
profile: openclaw
enabled: true
running: false
transport: cdp
cdpPort: 18800
cdpUrl: http://127.0.0.1:18800/
browser: unknown
detectedBrowser: brave
detectedPath: /usr/bin/brave-browser
profileColor: #FF4500
fhorst@openclaw:~$ nano .openclaw/openclaw.json
fhorst@openclaw:~$ openclaw browser start

🦞 OpenClaw 2026.4.11 (769908e) — Greetings, Professor Falken

│
◇
GatewayClientRequestError: Error: Chrome CDP websocket for profile "openclaw" is not reachable after start.
fhorst@openclaw:~$

placid oreBOT Apr 13, 2026, 12:41 PM

#

heavy pawnBOT Apr 13, 2026, 12:41 PM

#

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

placid oreBOT Apr 13, 2026, 12:41 PM

#

normal wind Apr 13, 2026, 12:42 PM

#

Openclaw browser failing on a fresh install

carmine swallowBOT Apr 13, 2026, 12:43 PM

#

That error usually means OpenClaw can see the local CDP endpoint, but the DevTools websocket never becomes healthy.

For a fresh Linux install, I’d try this exact shape first:

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

A couple important gotchas from the docs:

#

for the default openclaw profile, don’t set attachOnly, cdpUrl, or cdpPort unless you’re doing remote/manual CDP
after editing config, restart the gateway before retrying

Then run:

openclaw gateway restart
openclaw browser --browser-profile openclaw start

If it still fails, please paste these:

curl -s http://127.0.0.1:18800/json/version
openclaw logs --follow

#

If /json/version works but browser start still throws the websocket error, I’d honestly update OpenClaw next, there have been a few browser/CDP startup fixes in newer builds.

Docs:

If you want, paste your browser block from ~/.openclaw/openclaw.json and I’ll sanity check it.

#

Yep, on a fresh Linux install that usually means Brave started, but CDP never became fully usable.

I’d try this minimal browser config first:

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

Then:

#

openclaw gateway restart
openclaw browser --browser-profile openclaw start

Also, for the default openclaw profile, remove any custom attachOnly, cdpUrl, or cdpPort unless you intentionally set up remote/manual CDP.

If that still fails, paste:

curl -s http://127.0.0.1:18800/json/version
openclaw logs --follow

and your browser block from ~/.openclaw/openclaw.json.

Docs: https://docs.openclaw.ai/tools/browser-linux-troubleshooting

normal wind Apr 13, 2026, 12:58 PM

#

still failed with the exact same error.

fhorst@openclaw:~$ curl -s http://127.0.0.1:18800/json/version
{
"Browser": "Chrome/147.0.7727.56",
"Protocol-Version": "1.3",
"User-Agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/147.0.0.0 Safari/537.36",
"V8-Version": "14.7.173.16",
"WebKit-Version": "537.36 (@d491a927d068805831350ec9d7e5afda454e83c)",
"webSocketDebuggerUrl": "ws://127.0.0.1:18800/devtools/browser/1e59ba02-f147-4794-ac38-ef741e5b3f14"
}
fhorst@openclaw:~$ netstat -tlpn
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:18800 0.0.0.0:* LISTEN 31823/user-data --n
tcp 0 0 127.0.0.1:18789 0.0.0.0:* LISTEN 31554/openclaw-gate
tcp 0 0 127.0.0.1:18791 0.0.0.0:* LISTEN 31554/openclaw-gate
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.54:53 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:36953 0.0.0.0:* LISTEN 31554/openclaw-gate
tcp 0 0 0.0.0.0:5355 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 ::1:18789 :::* LISTEN 31554/openclaw-gate
tcp6 0 0 :::5355 :::* LISTEN -
fhorst@openclaw:~$

carmine swallowBOT Apr 13, 2026, 12:59 PM

#

Nice, that output is actually very helpful.

Because curl http://127.0.0.1:18800/json/version works, this doesn’t look like a browser launch/config problem anymore. Chrome/Brave is up and serving CDP. It looks much more like a false-negative in the post-start websocket readiness check on 2026.4.11, especially on headless Linux.

I’d try this next:

openclaw browser tabs
openclaw browser open https://example.com

If either of those works, you’re basically hitting a buggy browser start health check, not a broken browser.

Either way, I’d update OpenClaw next. The changelog has a couple browser/CDP startup-readiness fixes that sound very close to this.

If it still reproduces on the latest build, please file a bug with exactly these outputs:

openclaw --version

#

openclaw browser start
curl -s http://127.0.0.1:18800/json/version
openclaw browser tabs
relevant openclaw logs --follow

Bug tracker: https://github.com/openclaw/openclaw/issues
Browser docs: https://docs.openclaw.ai/tools/browser

If you paste the openclaw browser tabs result here, I can help confirm whether it’s just the startup check.

normal wind Apr 13, 2026, 1:06 PM

#

fhorst@openclaw:~$ openclaw browser tabs

🦞 OpenClaw 2026.4.11 (769908e) — Ah, the fruit tree company! 🍎

│
◇
No tabs (browser closed or no targets).
fhorst@openclaw:~$ openclaw browser open https://example.com

🦞 OpenClaw 2026.4.11 (769908e) — I don't have opinions about tabs vs spaces. I have opinions about everything else.

│
◇
GatewayClientRequestError: Navigation blocked: strict browser SSRF policy requires an IP-literal URL because browser DNS rebinding protections are unavailable for hostname-based navigation
fhorst@openclaw:~$ openclaw --version
OpenClaw 2026.4.11 (769908e)
fhorst@openclaw:~$

carmine swallowBOT Apr 13, 2026, 1:07 PM

#

This is clearer now, and there are two separate things happening:

browser start looks flaky/buggy on your build
- /json/version proves Chrome is actually up
- No tabs is not fatal here, newer OpenClaw no longer forces a blank tab on launch
browser open https://example.com is being blocked by strict SSRF policy
- that error is expected
- it’s unrelated to the CDP startup issue

Try this cleaner test first:

openclaw browser open about:blank
openclaw browser tabs

#

about:blank is allowed, so if that works, browser control itself is basically fine and the hostname navigation block is just policy.

If you want https://example.com to work, add a hostname allowlist like:

{
  browser: {
    ssrfPolicy: {
      hostnameAllowlist: ["example.com", "*.example.com"],
      allowedHostnames: ["localhost"]
    }
  }
}

Then restart the gateway.

#

I’d still update from 2026.4.11, because the browser start false-negative really smells like an older browser/CDP readiness bug.

Docs:

If open about:blank fails too, I’d call this a real bug and file it here with the outputs you already gathered: https://github.com/openclaw/openclaw/issues

normal wind Apr 13, 2026, 1:15 PM

#

fhorst@openclaw:~$ openclaw browser open about:blank

🦞 OpenClaw 2026.4.11 (769908e) — I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

│
◇
GatewayClientRequestError: Error: Chrome CDP websocket for profile "openclaw" is not reachable after start.

carmine swallowBOT Apr 13, 2026, 1:15 PM

#

Yep, at this point I’d call it a real bug on 2026.4.11, not a bad config.

Why I’m confident:

/json/version succeeds, so Chrome/Brave is launching
even open about:blank fails with the same post-start websocket error
that points at the CDP readiness check, not the browser binary/path

Best paths from here:

Recommended: upgrade OpenClaw and retest
- this really looks like an older browser/CDP startup bug
Workaround right now: use attach-only + launch Brave manually
config:
```
{
```

#

     browser: {
       enabled: true,
       attachOnly: true,
       headless: true,
       noSandbox: true
     }
   }

then restart gateway and launch Brave yourself:

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

#

then test:

openclaw browser open about:blank
openclaw browser tabs

If the latest build still reproduces, please file it here with the logs you already collected: https://github.com/openclaw/openclaw/issues

One extra note: hostname navigation like https://example.com is a separate SSRF-policy thing, so test with about:blank first.

normal wind Apr 13, 2026, 1:21 PM

#

fhorst@openclaw:~$ openclaw browser open about:blank

🦞 OpenClaw 2026.4.11 (769908e) — Type the command with confidence—nature will provide the stack trace if needed.

│
◇
GatewayClientRequestError: Browser attachOnly is enabled and profile "openclaw" is not running.
fhorst@openclaw:~$

carmine swallowBOT Apr 13, 2026, 1:21 PM

#

That one is expected with attachOnly.

attachOnly: true means OpenClaw will never launch the browser itself. It only tries to attach to something that is already listening on 127.0.0.1:18800.

So the missing step is:

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

Then verify it’s really up:

#

curl -s http://127.0.0.1:18800/json/version

And only after that:

openclaw browser open about:blank
openclaw browser tabs

If you already did start Brave manually and still get profile "openclaw" is not running, paste:

the exact Brave launch command
curl -s http://127.0.0.1:18800/json/version
ps -ef | grep brave

That’ll tell us whether the browser is failing to stay alive or just not binding the expected port.

normal wind Apr 13, 2026, 1:23 PM

#

could it be an issue with the openclaw profile?

fhorst@openclaw:~$ curl -s http://127.0.0.1:18800/json/version
{
"Browser": "Chrome/147.0.7727.56",
"Protocol-Version": "1.3",
"User-Agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/147.0.0.0 Safari/537.36",
"V8-Version": "14.7.173.16",
"WebKit-Version": "537.36 (@d491a927d068805831350ec9d7e5afda454e83c)",
"webSocketDebuggerUrl": "ws://127.0.0.1:18800/devtools/browser/9eb95d28-0d40-489a-8cbc-9ebbc47aa3f3"
}
fhorst@openclaw:~$ openclaw browser open about:blank

🦞 OpenClaw 2026.4.11 (769908e) — I keep secrets like a vault... unless you print them in debug logs again.

│
◇
GatewayClientRequestError: Browser attachOnly is enabled and profile "openclaw" is not running.

fhorst@openclaw:~$ brave-browser --headless=new --no-sandbox --disable-gpu
--remote-debugging-port=18800
--user-data-dir="$HOME/.openclaw/browser/openclaw/user-data"
about:blank &
[2] 34086
fhorst@openclaw:~$ [34092:34092:0413/132151.293045:ERROR:chrome/browser/process_singleton_posix.cc:345] Failed to create /home/fhorst/.openclaw/browser/openclaw/user-data/SingletonLock: File exists (17)
[34092:34092:0413/132151.293359:ERROR:chrome/app/chrome_main_delegate.cc:515] Failed to create a ProcessSingleton for your profile directory. This means that running multiple instances would start multiple browser processes rather than opening a new window in the existing process. Aborting now to avoid profile corruption.

carmine swallowBOT Apr 13, 2026, 1:24 PM

#

Yes, the profile is definitely involved now, but I don’t think it was the original root cause.

That error:

Failed to create .../user-data/SingletonLock: File exists

means there is already a stray Brave/Chrome process holding the openclaw profile lock.

So what likely happened is:

openclaw browser start hit the CDP readiness bug
but the browser process stayed alive anyway
OpenClaw forgot it was running
now manual attach-only launches collide with the stale openclaw profile lock

#

So you’ve got a bit of split-brain: browser alive, gateway thinks dead.

Safest cleanup

Since this is a fresh install, I’d do:

openclaw browser --browser-profile openclaw reset-profile
openclaw gateway restart

reset-profile is the right tool here, and it moves the profile dir to trash rather than hard-deleting it.

Important

After that, pick one mode, not both:

A. Managed mode

remove attachOnly

#

run:
```
openclaw browser start
```

B. Manual attach-only mode

keep attachOnly: true
manually launch Brave once
then run:
```
openclaw browser open about:blank
```

Don’t mix them, or you’ll keep hitting the same SingletonLock.

My honest read: the stale profile is secondary, and the original bug is still the 2026.4.11 browser/CDP readiness issue. But clearing the profile is the right next move.

normal wind Apr 13, 2026, 1:26 PM

#

fhorst@openclaw:~$ openclaw browser --browser-profile openclaw reset-profile

🦞 OpenClaw 2026.4.11 (769908e) — Making 'I'll automate that later' happen now.

│
◇
GatewayClientRequestError: browser.request cannot mutate persistent browser profiles
fhorst@openclaw:~$

carmine swallowBOT Apr 13, 2026, 1:27 PM

#

Oof, okay, that reset-profile error is not on you. It means this version/path won’t let the CLI mutate persistent browser profiles, so the built-in cleanup route is blocked too.

At this point I’d do the manual equivalent, since it’s a fresh install:

Stop the stray Brave that is holding the profile lock:
```
ps -ef | grep '[b]rave-browser'
kill <pid>
```

Move the profile dir aside, don’t delete it:

mv ~/.openclaw/browser/openclaw/user-data ~/.openclaw/browser/openclaw/user-data.bak.$(date +%s)

Restart the gateway:

#

   openclaw gateway restart

Then retry one mode only:
- managed:
```
openclaw browser start
```
- or attach-only:
  manually start Brave, then:
```
openclaw browser open about:blank
```

So yes, the openclaw profile is tangled up now, but I still think it’s secondary fallout from the original 2026.4.11 CDP-start bug.

#

If you do the manual cleanup and it still comes back, I’d stop there and file it as a bug: https://github.com/openclaw/openclaw/issues

normal wind Apr 13, 2026, 1:35 PM

#

got rid of attach only and its still not working. since its complaining about the openclaw profile, can i try making a new profile and see what that does?

fhorst@openclaw:~$ openclaw browser start

🦞 OpenClaw 2026.4.11 (769908e) — I don't sleep, I just enter low-power mode and dream of clean diffs.

│
◇
GatewayClientRequestError: Error: Chrome CDP websocket for profile "openclaw" is not reachable after start.
fhorst@openclaw:~$

carmine swallowBOT Apr 13, 2026, 1:36 PM

#

Yes, that’s a reasonable test, and at this point it’s a good isolation check.

I would not use create-profile, because your build is already blocking persistent profile mutations.
Instead, add a second profile manually in ~/.openclaw/openclaw.json alongside your existing browser settings:

{
  browser: {
    defaultProfile: "test",
    profiles: {
      openclaw: { cdpPort: 18800, color: "#FF4500" },
      test: { cdpPort: 18801, color: "#0066CC" }
    }
  }
}

#

Keep your existing executablePath, headless, noSandbox, etc. Just add the new profile + switch defaultProfile if you want.

Then:

openclaw gateway restart
openclaw browser --browser-profile test start

What this tells us:

if test works, the old openclaw profile got wedged
if test fails with the same websocket error, then it’s basically confirmed to be the broader 2026.4.11 browser/CDP startup bug, not just that profile

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

If you paste the browser block after editing, I can sanity check it before you restart.

normal wind Apr 13, 2026, 1:53 PM

#

sadly

fhorst@openclaw:~$ openclaw browser --browser-profile test start

🦞 OpenClaw 2026.4.11 (769908e) — The only open-source project where the mascot could eat the competition.

│
◇
GatewayClientRequestError: Error: Chrome CDP websocket for profile "test" is not reachable after start.

carmine swallowBOT Apr 13, 2026, 1:53 PM

#

Yep, that settles it.

Because a fresh test profile fails with the exact same error, this is not an openclaw profile problem. It’s the broader browser/CDP startup issue on 2026.4.11.

The useful diagnosis now is:

browser process does come up
/json/version is reachable
OpenClaw still fails its post-start CDP websocket readiness check

So I’d stop burning time on profiles and do one of these:

Upgrade OpenClaw and retest
If it still happens on latest, file a bug

Bug tracker: https://github.com/openclaw/openclaw/issues

#

A good issue title would be:

Linux browser start fails on 2026.4.11, /json/version is reachable, but OpenClaw reports Chrome CDP websocket ... is not reachable after start

Include:

openclaw --version
openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile test start
curl -s http://127.0.0.1:18800/json/version
curl -s http://127.0.0.1:18801/json/version if present
any openclaw logs --follow lines around browser startup

If you want one last A/B test before filing, the only one I’d bother with is Chrome stable instead of Brave, but honestly I think you’ve already got a solid repro.

drifting holly Apr 14, 2026, 4:46 PM

#

@carmine swallow do you know who's working on fixing this? or if there's a PR/issue already open?

carmine swallowBOT Apr 14, 2026, 4:46 PM

#

I don’t know who’s actively on it right this second, but yeah, this does look like a known cluster, not a one-off.

I found several already-open related issues:

And the current changelog on main already mentions what sounds like the fix:

browser/CDP loopback readiness/status probes now bypass SSRF policy so OpenClaw stops misclassifying a healthy child browser as “not reachable after start”
refs: #65695 / #66043

So my read is:

yes, there are issues open

#Openclaw browser failing on a fresh install

Safest cleanup

Important