#Browser won't start despite there being a browser available

1 messages · Page 1 of 1 (latest)

fading venture
#

civil@debian:~/.openclaw$ openclaw browser status

🦞 OpenClaw 2026.4.26 (be8c246) — Your .zshrc wishes it could do what I do.



profile: openclaw
enabled: true
running: false
transport: cdp
cdpPort: 18800
cdpUrl: http://127.0.0.1:18800
browser: unknown
detectedBrowser: unknown
detectedPath: auto
headless: true (linux-display-fallback)
profileColor: #FF4500
civil@debian:~/.openclaw$ openclaw browser start

🦞 OpenClaw 2026.4.26 (be8c246)
Your config is valid, your assumptions are not.



GatewayClientRequestError: INVALID_REQUEST: Error: Error: No supported browser found (Chrome/Brave/Edge/Chromium on macOS, Linux, or Windows).
civil@debian:~/.openclaw$

Despite it saying there's supposedly no browser found, there is definitely google chrome at /usr/bin/google-chrome. I also added this to openclaw.json top-level:
"browser": {
"enabled": true,
"headless": true,
"noSandbox": true,
"executablePath": "/usr/bin/google-chrome"
},

Still nothing. Plugin entries also has browser plugin enabled, still complaining that there's supposedly no browser.

silver hazelBOT
#

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

sudden martenBOT
#

That config key is real, but this line is the tell:

detectedPath: auto
detectedBrowser: unknown

If the running Gateway had loaded browser.executablePath, status should show that path. So I’d first assume the Gateway is not reading the config file you edited, or it hasn’t restarted/reloaded it.

Try:

openclaw config file
openclaw config get browser --json
ls -l /usr/bin/google-chrome
/usr/bin/google-chrome --version
#

Then set it via the CLI so it lands in the active config file:

openclaw config set browser.enabled true
openclaw config set browser.executablePath /usr/bin/google-chrome
openclaw config set browser.headless true
openclaw config set browser.noSandbox true
openclaw gateway restart

Then test:

openclaw browser --browser-profile openclaw doctor --deep
openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start
fading venture
#

I ran the re-setting of the config and restarted the gateway then tested, here's the output:
civil@debian:~/.openclaw$ openclaw browser --browser-profile openclaw doctor --deep

🦞 OpenClaw 2026.4.26 (be8c246)
I'll do the boring stuff while you dramatically stare at the logs like it's cinema.









OK gateway: browser control endpoint reachable
OK plugin: enabled
OK profile: openclaw (cdp)
OK browser: running
OK profiles: 2 configured
OK tabs: 1 visible, use target t1
OK live-snapshot: 3 nodes/lines
civil@debian:~/.openclaw$ openclaw browser --browser-profile openclaw status

🦞 OpenClaw 2026.4.26 (be8c246)
Deployed locally, trusted globally, debugged eternally.



profile: openclaw
enabled: true
running: false
transport: cdp
cdpPort: 18800
cdpUrl: http://127.0.0.1:18800
browser: unknown
detectedBrowser: unknown
detectedPath: auto
headless: true (linux-display-fallback)
profileColor: #FF4500
civil@debian:~/.openclaw$ openclaw browser --browser-profile openclaw start

🦞 OpenClaw 2026.4.26 (be8c246)
Automation with claws: minimal fuss, maximal pinch.



GatewayClientRequestError: INVALID_REQUEST: Error: Error: No supported browser found (Chrome/Brave/Edge/Chromium on macOS, Linux, or Windows).
civil@debian:~/.openclaw$

Still not working.

sudden martenBOT
#

That’s a really useful contradiction:

  • doctor --deep says CDP worked and snapshot worked
  • immediately after, status says not running + no executable path
  • start then fails at browser executable detection

So I’d stop looking at plugins — plugin is enabled. This smells like either the Gateway/runtime isn’t seeing the config value, or you’re hitting a stale/different browser control state.

Can you run this exact block?

openclaw config file
openclaw config get browser --json
openclaw config get browser.profiles.openclaw --json
openclaw gateway status
#
openclaw browser --json --browser-profile openclaw doctor --deep
openclaw browser --json --browser-profile openclaw status

/usr/bin/google-chrome --version
curl -s http://127.0.0.1:18800/json/version

The key fields I’m looking for:

  • config has browser.executablePath
  • JSON status has executablePath / detectedExecutablePath
  • cdpHttp vs cdpReady
  • whether Gateway status reports a different config path/user than your shell

If config get browser --json shows the path but browser status JSON still has executablePath: null / detectedExecutablePath: null, that’s bug-shaped in 2026.4.26 and worth filing with those outputs: https://github.com/openclaw/openclaw/issues

fading venture
#

civil@debian:~/.openclaw$ openclaw config file
openclaw config get browser --json
openclaw config get browser.profiles.openclaw --json
openclaw gateway status

🦞 OpenClaw 2026.4.26 (be8c246)
One CLI to rule them all, and one more restart because you changed the port.

~/.openclaw/openclaw.json
{
"enabled": true,
"executablePath": "/usr/bin/google-chrome",
"headless": true,
"noSandbox": true
}
Config path not found: browser.profiles.openclaw

🦞 OpenClaw 2026.4.26 (be8c246)
I'm not saying your workflow is chaotic... I'm just bringing a linter and a helmet.



Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-29.log
Command: /usr/bin/node /home/civil/.local/share/pnpm/global/5/.pnpm/openclaw@2026.4.26/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://192.168.0.96:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: running (pid 178221, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable

Listening: *:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
civil@debian:~/.openclaw$ openclaw browser --json --browser-profile openclaw doctor --deep
openclaw browser --json --browser-profile openclaw status

/usr/bin/google-chrome --version
curl -s http://127.0.0.1:18800/json/version




OK gateway: browser control endpoint reachable
OK plugin: enabled
OK profile: openclaw (cdp)
FAIL browser: not running; run openclaw browser start
OK profiles: 2 configured


profile: openclaw
enabled: true
running: false
transport: cdp
cdpPort: 18800
cdpUrl: http://127.0.0.1:18800
browser: unknown
detectedBrowser: unknown
detectedPath: auto
headless: true (linux-display-fallback)
profileColor: #FF4500
Google Chrome 147.0.7727.116
{
"Browser": "Chrome/147.0.7727.116",
"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.20",
"WebKit-Version": "537.36 (@dbcf1b1bfb506cc580859bcb5ff9460a8443af90)",
"webSocketDebuggerUrl": "ws://127.0.0.1:18800/devtools/browser/0497dbae-5bcb-46f5-a7ad-f3f7f42af7e1"
}
civil@debian:~/.openclaw$

sudden martenBOT
#

Yep, this is bug-shaped now.

Two important bits:

  1. Config path not found: browser.profiles.openclaw is normal — the default openclaw profile can be synthesized at runtime.
  2. The bad part is this:
config: executablePath=/usr/bin/google-chrome, headless=true
status: detectedPath=auto, headless=true (linux-display-fallback)

Status should show /usr/bin/google-chrome and headless: true (config). So the browser runtime is not seeing the browser config block even though the CLI config reader is.

Also, curl http://127.0.0.1:18800/json/version proves Chrome/CDP is already running on that port, so this isn’t “Chrome missing.”

I’d try upgrading off 2026.4.26 first:

#
pnpm add -g openclaw@latest
hash -r
openclaw --version
openclaw gateway restart
openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start

If it still happens after upgrading, please file this as a GitHub issue with the exact outputs you posted: https://github.com/openclaw/openclaw/issues

Useful title: Browser runtime ignores root browser.executablePath on 2026.4.26

Include that curl output too — it’s the smoking gun. 🦐

fading venture
#

Generate a one-sentence statement of what is broken, based only on observed evidence.

sudden martenBOT
#

OpenClaw’s browser status/start path is not honoring the configured browser.executablePath even though /usr/bin/google-chrome exists and CDP is reachable on port 18800.

fading venture
#

Provide the shortest deterministic repro path supported by direct observation.

sudden martenBOT
#
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 browser start

Observed result: status still shows detectedPath: auto, and start fails with No supported browser found.

fading venture
#

State the expected result using a concrete reference such as prior observed behavior, attached docs, or a known-good version.

sudden martenBOT
#

Expected: per the browser docs, browser.executablePath should override auto-detection, so openclaw browser status should report /usr/bin/google-chrome instead of detectedPath: auto, and openclaw browser start should use that binary rather than failing with No supported browser found.

fading venture
#

Describe only the observed result, including user-visible errors and cited evidence.