openclaw - 💡(How to fix) Fix [Bug]: Browser runtime ignores configured executablePath (regression, original #73617 bot-closed prematurely) [2 comments, 3 participants]

This is a follow-up to #73617, which was closed prematurely by a bot (clawsweeper[bot]) claiming the fix was on main, despite the issue persisting in the latest release.

Summary

The OpenClaw browser runtime ignores the configured browser.executablePath (and browser.profiles.openclaw.executablePath) in the 2026.4.27 release. The CLI reports detectedPath: auto and detectedBrowser: unknown even when Chrome is installed and config has the path set.

Steps to Reproduce

# Minimal reproduction
openclaw config set browser.executablePath /usr/bin/google-chrome
openclaw config set browser.headless true
openclaw config set browser.noSandbox true
openclaw gateway restart
openclaw browser status

• openclaw config get browser --json confirms executablePath: "/usr/bin/google-chrome"
• /usr/bin/google-chrome --version returns Google Chrome 147.0.7727.116
• CDP responds on port 18800
• But openclaw browser status still shows detectedPath: auto

Profile-level workaround also does not work. Setting browser.profiles.openclaw.executablePath has the same result.

Root Cause: Dual State Paths

The browser plugin has two separate config state paths:

1. HTTP server (port 18791) — initialized at gateway startup, reads current config ✅
2. Gateway WebSocket handler (port 18789) — initialized lazily, uses a stale/cached config snapshot that never picks up executablePath, noSandbox, or other browser settings ❌

The CLI (openclaw browser status, openclaw browser start) routes through the gateway WebSocket handler, which has the stale snapshot. Direct HTTP calls to port 18791 return the correct values.

Evidence

• curl to http://127.0.0.1:18791/ returns correct executablePath and noSandbox
• CLI/gateway WebSocket returns executablePath: null and noSandbox: false
• HTTP API can start the browser; the CLI cannot

Workaround

token=$(python3 -c "import json; print(json.load(open(~/.openclaw/openclaw.json))[gateway][auth][token])")
# Check status (works)
curl -s -H "Authorization: Bearer $token" http://127.0.0.1:18791/ | python3 -m json.tool
# Start browser (works)
curl -s -X POST -H "Authorization: Bearer $token" "http://127.0.0.1:18791/start?profile=openclaw"

Related Issues

• #53004 — same root cause (WebSocket/handler stale config)
• #59527 — same root cause
• Original closed issue: #73617

Additional Context

• OpenClaw version: 2026.4.27 (also confirmed broken on 2026.4.26)
• Chrome: Google Chrome 147.0.7727.116
• OS: Linux (Debian trixie)

In original issue #73617, @martingarramon did a source trace and found that the status route only checks profile-level executablePath with no fallback to resolved.executablePath (Finding 2), and the value is being lost before reaching the browser runtime config snapshot (Finding 1). This goes deeper than both findings — even profile-level config is lost through the WebSocket path.