Browser problem | Friends of the Crustacean 🦞🤝 | Page 1

reef raptor Apr 14, 2026, 4:43 PM

#

Hi everyone, I have a browser problem and here is what OpenClaw told me. Please let me know how to fix it. Thank you in advance.

The browser tool issue in this VM:

Chrome process dies immediately when OpenClaw tries to manage it. The CDP connection drops because Chrome can't stay alive — it crashes within seconds of starting.

Why it happens:

• VM environment has VAAPI/graphics errors (hardware acceleration issues)
• Shared memory descriptor problems
• Chrome starts with --no-sandbox but still crashes

What we tried:

• OpenClaw v2026.4.14 update (included SSRF/browser fix) — didn't fix it
• Manually starting Chrome with various flags — dies within seconds
• The openclaw browser start command shows "running: true" but Chrome dies when we try to navigate to HTTPS sites

Current status:

• ✅ Basic HTTP navigation works (example.com)
• ❌ HTTPS sites fail (google.com, twitter.com)
• ❌ X.com crashes CDP immediately
• Browser tool is unreliable in this VM — it's a fundamental Chrome/VM incompatibility, not a config issue

sterile lagoonBOT Apr 14, 2026, 4:43 PM

#

sand pawnBOT Apr 14, 2026, 4:43 PM

#

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

sterile lagoonBOT Apr 14, 2026, 4:43 PM

#

long pierBOT Apr 14, 2026, 4:46 PM

#

Let me verify the docs and the actual browser behavior notes before I answer.

#

I found the browser docs and the Linux browser troubleshooting page. I’m checking whether there’s a more specific VM-safe path than “just use Chrome” before I answer.

#

That sounds like the browser binary itself is crashing, not OpenClaw’s browser layer.

What I’d do, in order:

First confirm the exact build:

pnpm openclaw --version

If this is Ubuntu/Debian and you’re using snap Chromium, switch off that first. The OpenClaw docs explicitly call out snap Chromium as a common cause of CDP/browser startup failures. Use a real Chrome/Brave .deb, then set:

{
  browser: {
    enabled: true,
    executablePath: "/usr/bin/google-chrome-stable",
    headless: true,

#

    noSandbox: true
  }
}

If the VM still kills Chrome, my honest recommendation is: stop launching the browser inside that VM. Use browser control on the machine that can actually keep Chrome alive:
- best: run a node host on that machine, or
- use remote CDP with attachOnly: true:

{
  browser: {
    enabled: true,
    defaultProfile: "remote",
    profiles: {
      remote: {

#

        cdpUrl: "http://HOST_THAT_RUNS_CHROME:9222",
        attachOnly: true
      }
    }
  }
}

If you must stay in the VM, try the docs’ attach-only workaround:

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

#

If that manual browser also dies on HTTPS, then this is not an OpenClaw config bug. It’s the VM/browser stack.

So, short version:
Best fix: move browser automation to a stable host and attach via node host or remote CDP.
Second best: replace snap Chromium with real Chrome/Brave.
Least promising: keep fighting the current VM.

Docs:

If you paste these, I can narrow it down fast:

pnpm openclaw --version
pnpm openclaw status --all

#

google-chrome-stable --version || chromium-browser --version

reef raptor Apr 14, 2026, 10:30 PM

#

VM TERMINAL:
clawdbot@clawdbot-VirtualBox:~$ curl http://192.168.68.61:9222/json/version
{
"Browser": "Chrome/147.0.7727.56",
"Protocol-Version": "1.3",
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36",
"V8-Version": "14.7.173.16",
"WebKit-Version": "537.36 (@b28eac7a1a97ec8d7bc58eca0242958254be494d)",
"webSocketDebuggerUrl": "ws://192.168.68.61:9222/devtools/browser/fcf6959c-27b2-4594-b0d2-8df26f7621e3"
}

BOT MESSAGE:
The issue is Chrome's CDP returns WebSocket URLs pointing to 127.0.0.1:9222 — the VM can't connect to that. Portproxy handles HTTP but not WebSocket upgrades properly.

This is a known limitation of Chrome's remote debugging in this configuration. The browser tool fundamentally can't work in this setup.

VM can reach Windows Chrome on 192.168.68.61:9222, but the Chrome still doesn't work. Anyone has the solution? Thanks.

long pierBOT Apr 14, 2026, 10:32 PM

#

I think the earlier bot diagnosis is off.

Your curl output shows:

"webSocketDebuggerUrl": "ws://192.168.68.61:9222/devtools/browser/..."

So this is not the old “Chrome returned 127.0.0.1” problem. CDP discovery is already giving the VM a LAN-reachable WS URL.

What I’d check next:

Use a raw remote CDP profile, not user / existing-session
Those are host-local only.

#

{
  browser: {
    enabled: true,
    defaultProfile: "remote",
    ssrfPolicy: {
      dangerouslyAllowPrivateNetwork: true
    },
    profiles: {
      remote: {
        cdpUrl: "http://192.168.68.61:9222",
        attachOnly: true,
        color: "#00AA00"
      }
    }
  }

#

Restart the gateway, then test with that profile explicitly:

pnpm openclaw browser open https://example.com --browser-profile remote
pnpm openclaw browser tabs --browser-profile remote

If it still fails, grab the exact browser error from:

pnpm openclaw logs --follow

Why I’m pointing at SSRF/profile mode first:

#Browser problem