On this page
On this page
Tools
Browser troubleshooting
Problem: Failed to start Chrome CDP on port 18800
Root cause
On Ubuntu and most Linux distros, apt install chromium installs a snap
wrapper, not a real browser:
Snap's AppArmor confinement interferes with how OpenClaw spawns and monitors the browser process.
Other common Linux launch failures:
-
Socket path too long: Chromium cannot fit its process-singleton Unix socket under a long temporary-directory path. Managed launches use/tmpwhen the inherited temp path exceeds 50 bytes, leaving room for Chromium's private directory and socket name. This does not change the Gateway's environment or managed browser profile directory. -
GPU process isn't usable. Goodbye.: Chromium exhausted its GPU fallback options. Check the preceding Chrome stderr for the first GPU-process failure. Inherited jemallocLD_PRELOADwithMALLOC_CONF=background_thread:truecan make the zygote multi-threaded before fork, causing GPU subprocess launch failures (error_code=1002). Managed Chrome launches stripMALLOC_CONFand jemalloc entries fromLD_PRELOAD, preserving other preload libraries and the Gateway's own allocator settings. Wrappers that re-add these variables must remove them before executing Chrome. Managed headless launches already use--headless=new --disable-gpu; try removing custom GPU flags frombrowser.extraArgsand verify the configured browser executable works on the host. Adding--enable-unsafe-swiftshaderlowers WebGL security guarantees and is not a general fix for this fatal error. -
The profile appears to be in use by another Chromium process: staleSingleton*lock files in the managed profile directory. OpenClaw removes these locks and retries once when the lock points at a dead process on the current host. Locks naming another hostname are preserved until you verify that the profile is no longer in use, including after a machine rename. -
Missing X server or $DISPLAY: a visible browser was explicitly requested on a host without a desktop session. Local managed profiles use headless mode by default, including when a desktop session is available. If you setOPENCLAW_BROWSER_HEADLESS=0,browser.headless: false, orbrowser.profiles.<name>.headless: false, remove that headed override, setOPENCLAW_BROWSER_HEADLESS=1, startXvfb, runopenclaw browser start --headlessfor a one-shot managed launch, or run OpenClaw in a real desktop session.
Solution 1: install Google Chrome (recommended)
Update ~/.openclaw/openclaw.json:
Solution 2: use snap Chromium in attach-only mode
If you must keep snap Chromium, configure OpenClaw to attach to a manually-started browser instead of launching it:
Start Chromium manually:
Optionally auto-start it with a systemd user service:
Missing shared libraries
error while loading shared libraries: the browser binary exists, but the
host is missing a required runtime library. openclaw browser doctor runs
the local managed executable with --version and reports the loader error
as a failed Chromium executable check. Install the named library through
your distribution's package manager, or use a browser package that includes
the required dependencies. Downloading Playwright's Chromium alone does not
install system libraries. The probe does not start a browser or touch its
profile; ordinary status checks remain passive.
Verify the browser works
OpenClaw logs a managed browser as started only after HTTP discovery and a CDP command succeed. A child that exits during startup returns its exit code or signal and captured stderr to the browser tool, and logs the failure. Abnormal exits after readiness are also logged with bounded stderr. After correcting the executable or launch arguments, retry; if the browser remains unavailable, use another configured profile or an alternative tool.
These calls go to the OpenClaw browser control service, not to the Chrome CDP
port used above. Its port is derived from gateway.port (default 18791 =
gateway port + 2), so adjust the number if you moved the Gateway port. jq only
pretty-prints the response; drop the pipe if you do not have it installed.
Config reference
| Option | Description | Default |
|---|---|---|
browser.enabled |
Enable browser control | true |
browser.executablePath |
Path to a Chromium-based browser binary (Chrome/Brave/Edge/Chromium) | auto-detected (prefers the OS default browser when Chromium-based) |
browser.headless |
Run without GUI | true |
OPENCLAW_BROWSER_HEADLESS |
Per-process override for local managed browser headless mode | unset |
browser.noSandbox |
Add --no-sandbox flag (needed for some Linux setups) |
false |
browser.attachOnly |
Do not launch a browser; only attach to an existing one | false |
On Raspberry Pi, older VPS hosts, or slow storage, use a manually launched
browser with attachOnly when Chrome needs more time to expose its CDP HTTP
endpoint or become ready than the managed-browser deadline permits.
Problem: No Chrome tabs found for profile="user"
You are using the user (existing-session / Chrome MCP) profile and no
tabs are open to attach to.
Fix options:
- Use the managed browser instead:
openclaw browser --browser-profile openclaw start(or setbrowser.defaultProfile: "openclaw"). - Keep local Chrome running with at least one open tab, then retry with
--browser-profile user.
Notes:
useris host-only. On Linux servers, containers, or remote hosts, prefer CDP profiles instead.userand otherexisting-sessionprofiles share the current Chrome MCP limits: ref-driven actions only, one file per upload, no dialogtimeoutMsoverrides, nowait --load networkidle, and noresponsebody, PDF export, download interception, or batch actions.- Local
openclaw-driver profiles get acdpPortallocated when OpenClaw creates them; a profile you declare by hand must setcdpPortitself, orcdpUrlfor remote CDP. - Remote CDP profiles accept
http://,https://,ws://, andwss://. Use HTTP(S) for/json/versiondiscovery, or WS(S) when your browser service gives you a direct DevTools socket URL.