[ws] ⇄ res ✗ browser.request 15149ms errorCode=UNAVAILABLE errorMessage=Error | Friends of the Crustacean 🦞🤝 | Page 1

modest cape Feb 22, 2026, 9:22 AM

#

what command can check this

austere yachtBOT Feb 22, 2026, 9:22 AM

#

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

vital heronBOT Feb 22, 2026, 9:26 AM

#

Run this first (it’s the best “one command” report, and it’s safe to paste — tokens get redacted):

openclaw status --all

If you want to catch the exact reason for that browser.request … UNAVAILABLE … Error channel id:..., tail logs and retry the action once:

openclaw logs --follow

And since the failing tool call is browser.request, also check the browser subsystem:

openclaw browser status

#

If you paste the output of openclaw status --all (+ your openclaw --version), we can usually pinpoint whether it’s a Discord permission/channel/thread issue vs. an actual browser service problem.

Docs refs:

https://docs.openclaw.ai/help/faq (see “First 60 seconds if something’s broken”)
https://docs.openclaw.ai/gateway/troubleshooting

modest cape Feb 22, 2026, 9:28 AM

#

Item │ Value │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ Dashboard │ http://127.0.0.1:18789/ │
│ OS │ linux 6.10.14-linuxkit (x64) · node 22.22.0 │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ available · pnpm · npm update 2026.2.21-2 · deps stale │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · │
│ │ reachable 51ms · auth token · 54eb5c616a6b (172.18.0.2) │
│ │ app unknown linux 6.10.14-linuxkit │
│ Gateway service │ systemd not installed │
│ Node service │ systemd not installed │
│ Agents │ 1 · 1 bootstrapping · sessions 1 · default main active │
│ │ 31m ago │
│ Memory │ 0 files · 0 chunks · sources memory · plugin memory-core │
│ │ · vector unknown · fts ready · cache on (0) │
│ Probes │ skipped (use --deep) │
│ Events │ none │
│ Heartbeat │ 30m (main) │
│ Sessions │ 1 active · default stepfun/step-3.5-flash:free (256k │
│ │ ctx) · ~/.openclaw/agents/main/sessions/sessions.json │

vital heronBOT Feb 22, 2026, 9:32 AM

#

Your openclaw status --all looks fine for the Gateway itself (reachable, auth token set). Next I’d check two things: (A) can Discord see that channel id? and (B) is the browser subsystem actually up?

A) Verify the Discord channel/thread id is valid (and the bot can see it)

Run:

openclaw message channel info --channel discord --target channel:1475060106231283746

If that errors, it usually means wrong/old ID, bot isn’t in that channel/thread, or the thread is archived/locked.
If you don’t know what channels the bot can see, list them:

openclaw message channel list --channel discord --guild-id <YOUR_GUILD_ID>

B) Check the browser tool itself

#

Run:

openclaw browser status
openclaw browser profiles

(and if needed)

openclaw browser start --browser-profile openclaw

C) Grab the exact failure from logs (best signal)

openclaw logs --follow

#

If you paste the output of (A) + openclaw browser status + the few log lines around the failure, we can tell if it’s a Discord routing/permission issue vs. browser not running.

modest cape Feb 22, 2026, 9:33 AM

#

◇
profile: openclaw
enabled: true
running: false
cdpPort: 18800
cdpUrl: http://127.0.0.1:18800
browser: unknown
detectedBrowser: chromium
detectedPath: /usr/bin/chromium
profileColor: #FF4500

#

status is find but cant start

#

2026-02-22T09:34:24.356Z [ws] ⇄ res ✗ browser.request 15223ms errorCode=UNAVAILABLE errorMessage=Error: Failed to start Chrome CDP on port 18800 for profile "openclaw". conn=cf56342d…10e7 id=a6f17863…5f0c

vital heronBOT Feb 22, 2026, 9:37 AM

#

That output means the browser profile is enabled but the browser isn’t actually running, so any browser.request / browser tool call will fail until you start it.

Try:

openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw tabs

If start fails (common on LinuxKit/Docker), set it to headless + no-sandbox and restart the gateway, then retry:

openclaw config set browser.headless true --strict-json
openclaw config set browser.noSandbox true --strict-json
openclaw gateway restart
openclaw browser --browser-profile openclaw start

#

If you still see Error channel id:1475060106231283746, run this to confirm Discord can resolve that thread/channel (permissions/archived thread/etc.):

openclaw message channel info --channel discord --target channel:1475060106231283746

Paste the output of the failing start (or the log lines from openclaw logs --follow right when you run it) and we can pinpoint the exact blocker.

#

Yep — that browser status output is the smoking gun: profile is enabled, but running: false, so the agent’s browser.request will just time out (yours shows ~15s, which matches the default CLI timeout).

Try starting it with a longer timeout so you get a real error back:

openclaw browser --browser-profile openclaw --timeout 60000 start
openclaw browser --browser-profile openclaw status

If it still won’t start, do these two (very common on LinuxKit/Docker / restricted sandbox environments):

openclaw config set browser.headless true --strict-json
openclaw config set browser.noSandbox true --strict-json
openclaw gateway restart
openclaw browser --browser-profile openclaw --timeout 60000 start

#

If it fails again, paste the exact error text from openclaw browser … start plus the log lines from:

openclaw logs --follow

(Usually the log will say something like “Failed to start Chrome CDP…” or complain about the Chromium binary being a snap wrapper / missing deps, and then we can pick the right fix.)

#

That error is coming from Chrome/Chromium never bringing up the CDP endpoint on 127.0.0.1:18800 within 15s (so OpenClaw kills it and reports “Failed to start Chrome CDP…”).

On LinuxKit / container-ish environments this is usually one of these:

1) You’re effectively headless (no display), but browser is not configured headless

Set these and restart:

openclaw config set browser.headless true --strict-json
openclaw config set browser.noSandbox true --strict-json
openclaw gateway restart
openclaw browser --browser-profile openclaw --timeout 60000 start

2) Chromium binary is a snap/wrapper or otherwise can’t run properly

Quick check:

#

ls -l /usr/bin/chromium
/usr/bin/chromium --version

If it’s a snap wrapper / weird stub, the most reliable fix is to install Google Chrome (deb) and point OpenClaw at it (docs: https://docs.openclaw.ai/tools/browser-linux-troubleshooting):

openclaw config set browser.executablePath "/usr/bin/google-chrome-stable"
openclaw config set browser.headless true --strict-json
openclaw config set browser.noSandbox true --strict-json
openclaw gateway restart
openclaw browser --browser-profile openclaw start

3) Chromium is crashing immediately (missing deps) — confirm by running it manually

Run this and paste the stderr if it errors:

#

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

If you share:

output of openclaw browser --browser-profile openclaw status
output of ls -l /usr/bin/chromium && /usr/bin/chromium --version
any stderr from the manual chromium command

…I can tell you which branch you’re in and the exact fix.

modest cape Feb 22, 2026, 9:43 AM

#

profile: openclaw
enabled: true
running: false
cdpPort: 18800
cdpUrl: http://127.0.0.1:18800/
browser: unknown
detectedBrowser: chromium
detectedPath: /usr/bin/chromium
profileColor: #FF4500

#

Chromium 145.0.7632.109 built on Debian GNU/Linux 12 (bookworm)

vital heronBOT Feb 22, 2026, 9:50 AM

#

Cool — that confirms it’s real Debian Chromium, not the snap wrapper.

So the failure is almost certainly: Chromium is failing to launch far enough to expose CDP on 127.0.0.1:18800 (most commonly because you’re in a headless/container environment but browser.headless isn’t enabled, or sandboxing blocks it).

1) Make sure OpenClaw is launching Chromium in headless + no-sandbox mode

Run:

openclaw config get browser

Then set (and restart gateway):

openclaw config set browser.headless true --strict-json
openclaw config set browser.noSandbox true --strict-json

#

openclaw gateway restart
openclaw browser --browser-profile openclaw --timeout 60000 start
openclaw browser --browser-profile openclaw status

2) If it still fails: run Chromium manually and see the real stderr

This will tell us immediately what’s wrong (missing display, sandbox, perms, etc.):

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

In another terminal, test if CDP came up:

#

curl -s http://127.0.0.1:18800/json/version

Paste:

the output of curl …/json/version (or the error)
and any stderr Chromium prints

…and we can pick the exact fix (sometimes it’s just permissions on the user-data-dir, sometimes a missing lib in the image).

modest cape Feb 22, 2026, 10:06 AM

#

[831:831:0222/100543.594535:ERROR:chrome/browser/process_singleton_posix.cc:363] The profile appears to be in use by another Chromium process (85) on another computer (f81c805790a7). Chromium has locked the profile so that it doesn't get corrupted. If you are sure no other processes are using this profile, you can unlock the profile and relaunch Chromium.
[831:831:0222/100543.594730:ERROR:chrome/browser/ui/views/message_box_dialog.cc:199] Unable to show message box: Chromium - The profile appears to be in use by another Chromium process (85) on another computer (f81c805790a7). Chromium has locked the profile so that it doesn't get corrupted. If you are sure no other processes are using this profile, you can unlock the profile and relaunch Chromium.

vital heronBOT Feb 22, 2026, 10:10 AM

#

That’s the issue: Chromium is refusing to start because the OpenClaw profile dir is locked (~/.openclaw/browser/openclaw/user-data). This usually happens if:

a previous Chromium process is still running with that --user-data-dir, or
you ran the manual Chromium test using the same --user-data-dir while OpenClaw is also trying to start it.

Do this:

1) Stop any OpenClaw-managed browser + find the stray Chromium

openclaw browser --browser-profile openclaw stop
ps aux | grep -i chromium | grep user-data

If you see a Chromium command using ~/.openclaw/browser/openclaw/user-data, stop it (gentle kill):

kill <PID>

#

2) Easiest clean fix: reset the OpenClaw browser profile (moves it to Trash)

This clears the lock safely:

openclaw browser --browser-profile openclaw reset-profile
openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw tabs

Tip for manual testing

If you run Chromium manually again, use a different profile dir (so it won’t fight OpenClaw):

/usr/bin/chromium --headless=new --no-sandbox --disable-gpu \
  --remote-debugging-port=18800 \
  --user-data-dir=/tmp/chromium-test-profile \
  about:blank

#

If reset-profile + start still fails, paste the output of:

openclaw browser --browser-profile openclaw --timeout 60000 start
openclaw logs --follow

modest cape Feb 22, 2026, 10:29 AM

#

rm -rf ~/.openclaw/browser/openclaw/user-data

#[ws] ⇄ res ✗ browser.request 15149ms errorCode=UNAVAILABLE errorMessage=Error

A) Verify the Discord channel/thread id is valid (and the bot can see it)

B) Check the browser tool itself

C) Grab the exact failure from logs (best signal)

1) You’re effectively headless (no display), but browser is not configured headless

2) Chromium binary is a snap/wrapper or otherwise can’t run properly

3) Chromium is crashing immediately (missing deps) — confirm by running it manually

1) Make sure OpenClaw is launching Chromium in headless + no-sandbox mode

2) If it still fails: run Chromium manually and see the real stderr

1) Stop any OpenClaw-managed browser + find the stray Chromium

2) Easiest clean fix: reset the OpenClaw browser profile (moves it to Trash)

Tip for manual testing