OpenClaw Browser Control Service Bug Report

Summary

Browser control service fails to start Chrome CDP with "Failed to start Chrome CDP on port 18800" error, but Chrome itself works perfectly when started manually.

Environment

• OpenClaw Version: 2026.2.26 (bc50708)
• OS: CentOS (Linux 4.19.112-2.el8.x86_64)
• Node.js: v24.13.0
• Chrome: Google Chrome 143.0.7499.40
• Shell: bash
• Config: ~/.openclaw/openclaw.json

Steps to Reproduce

1. Configure browser in openclaw.json:

{
  "browser": {
    "enabled": true,
    "executablePath": "/usr/bin/google-chrome",
    "headless": true,
    "noSandbox": true,
    "attachOnly": false,
    "defaultProfile": "openclaw"
  }
}

2. Run openclaw gateway start
3. Call browser tool: openclaw browser status or openclaw browser open
4. Observe timeout error

Expected Behavior

Browser should start successfully and report:

{
  "running": true,
  "cdpReady": true,
  "browser": "chrome"
}

Actual Behavior

{
  "running": false,
  "cdpReady": false,
  "browser": "unknown",
  "error": "Can't reach the OpenClaw browser control service (timed out after 15000ms)"
}

Error Messages

From Logs

[tools] browser failed: Can't reach the OpenClaw browser control service (timed out after 15000ms). Restart the OpenClaw gateway (OpenClaw.app menubar, or `openclaw gateway`). Do NOT retry the browser tool — it will keep failing. Use an alternative approach or inform the user that the browser is currently unavailable.

{"subsystem":"gateway/ws"} | {"level":"INFO"} | ⇄ res ✗ browser.request 16218ms errorCode=UNAVAILABLE errorMessage=Error: Failed to start Chrome CDP on port 18800 for profile "openclaw"

From CLI

Error: gateway timeout after 15000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/xunye/.openclaw/openclaw.json
Bind: loopback

Diagnosis Evidence

1. Chrome Binary Works Correctly

$ /usr/bin/google-chrome --version
Google Chrome 143.0.7499.40

2. Manual Chrome CDP Start Succeeds

$ /usr/bin/google-chrome --headless --no-sandbox --remote-debugging-port=18800 --disable-gpu about:blank &
# Result: DevTools listening on ws://127.0.0.1:18800/devtools/browser/...
# Port 18800: SUCCESSFULLY OCCUPIED

3. Symbolic Links Are Correct

/usr/bin/google-chrome -> /etc/alternatives/google-chrome -> /opt/google/chrome/google-chrome

4. Browser Control Service Starts

{"subsystem":"browser/server"} | {"level":"INFO"} | Browser control listening on http://127.0.0.1:18791/ (auth=token)
{"subsystem":"browser/service"} | {"level":"INFO"} | Browser control service ready (profiles=2)

5. But CDP Connection Times Out

{"subsystem":"gateway/ws"} | {"level":"INFO"} | ⇄ res ✗ browser.request 16218ms errorCode=UNAVAILABLE errorMessage=Error: Failed to start Chrome CDP on port 18800 for profile "openclaw"

Analysis

Working Components

• ✅ Gateway service: Running on ws://127.0.0.1:18789
• ✅ Browser control server: Running on http://127.0.0.1:18791
• ✅ Chrome binary: Executable and correct version
• ✅ Manual Chrome CDP: Starts and listens on port 18800

Failing Component

• ❌ Browser control service → Chrome CDP initialization: TIMEOUT after 15 seconds

Root Cause Hypothesis

The browser control service successfully starts Chrome but fails during CDP initialization phase. Possible causes:

1. Race condition between service startup and CDP detection
2. Incorrect CDP connection timeout/retry logic
3. Chrome profile/user-data-dir configuration issue with managed profiles
4. Missing or incorrect environment variables for headless CDP

Workarounds

1. Use curl for static pages: This bypasses the browser tool entirely
2. Manual Chrome management: Start Chrome manually and use direct CDP connection

Additional Context

• Chrome warnings observed (non-critical):

  • libva error: va_getDriverName() failed with unknown libva error
  • Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/portal/desktop

• System has other Chrome instances running (browser usage, etc.)

• Disk space: Available (32G free on /tmp)

Impact

• Browser tool completely unusable
• All automated workflows requiring browser automation fail
• Affects only Linux environment (likely works on macOS)