#Search the web with agent using Chromium

1 messages · Page 1 of 1 (latest)

dapper pastureBOT Feb 15, 2026, 10:40 PM

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

craggy blazeBOT Feb 15, 2026, 10:43 PM

That error isn’t Chromium-specific — it means the CLI can’t talk to the Gateway WebSocket at ws://127.0.0.1:18789 within 15s.

The confusing bit: your diagnosis says 18789 is in use by openclaw-gateway, so the gateway process exists, but it’s likely wedged or your service is running a different config/profile than your CLI.

1) Check whether the gateway is actually reachable

Run and paste the output:

openclaw gateway status

Pay attention to:

RPC probe: ok|failed
Probe target: ...
Config (cli) vs Config (service) (if it shows both)

2) If `RPC probe` is failed: restart the gateway

(Especially if you updated OpenClaw recently.)

openclaw gateway restart

Then retry:

openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://example.com

3) If `Config (cli)` and `Config (service)` differ

That usually means the systemd/launchd service is pointing at a different profile/state dir than your current shell.

Fix by reinstalling the service from the environment/profile you want:

openclaw gateway install --force
openclaw gateway restart

4) Logs (most useful next artifact)

In another terminal:

openclaw logs --follow

Then run the openclaw browser ... open https://example.com command again and paste what errors appear in the log.

Notes

spawn tailscale ENOENT is harmless unless you’re trying to use Tailscale features.
Docs refs: https://docs.openclaw.ai/gateway/troubleshooting and https://docs.openclaw.ai/tools/browser

If you paste openclaw gateway status here, I can tell you which branch (wedged gateway vs config mismatch vs auth/handshake) you’re in.

Gateway side looks healthy now (RPC probe: ok, listening on 127.0.0.1:18789), so the earlier gateway timeout after 15000ms is almost certainly the browser RPC call taking longer than the CLI’s default 15s timeout (often because Chrome/Chromium startup on a server is slow / stuck / missing deps).

1) Re-run with a bigger timeout + watch logs

In one terminal:

openclaw logs --follow

In another terminal:

openclaw browser --browser-profile openclaw --timeout 60000 start
openclaw browser --browser-profile openclaw --timeout 60000 open https://example.com
openclaw browser --browser-profile openclaw tabs

If it still times out, paste the log lines that appear right when you run start.

2) If this is a headless VPS, enable headless mode

On servers without a GUI, you usually want:

openclaw config set browser.headless true
openclaw config set browser.noSandbox true
openclaw gateway restart

Then retry the openclaw browser ... start/open commands (with --timeout 60000).

3) Common Linux gotcha: Snap Chromium

If you’re on Ubuntu and Chromium came from snap, OpenClaw spawning it can behave badly. The docs recommend installing Google Chrome (.deb) and pointing browser.executablePath at it.

Linux runbook (worth following): https://docs.openclaw.ai/tools/browser-linux-troubleshooting

4) Separate (but recommended): run Doctor

Your gateway status is warning that the systemd service is pinned to an nvm Node path (can break after upgrades). This won’t usually cause the browser timeout, but it’ll save you pain later:

openclaw doctor
# or: openclaw doctor --repair

If you paste what openclaw logs --follow shows during openclaw browser ... start, we can pinpoint whether it’s “slow startup” vs “can’t spawn chromium” vs “snap confinement”.

Can you paste the actual log lines? (Right now your message cuts off after “logs show:”)

Best way to capture the useful bit:

Reproduce once:

openclaw browser --browser-profile openclaw --timeout 60000 start
openclaw browser --browser-profile openclaw --timeout 60000 open https://example.com

Immediately dump a fresh tail and paste it here:

openclaw logs --limit 200 --plain

Also paste this (it often contains the smoking gun: chosen browser, CDP port, etc.):

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

What I’m looking for in the logs is one of these patterns:

Failed to start Chrome CDP on port 18800 → on Ubuntu this is very often Snap Chromium; fix is in the Linux browser troubleshooting doc: https://docs.openclaw.ai/tools/browser-linux-troubleshooting
No usable browser found / executablePath issues → you need to install Chrome/Brave and/or set browser.executablePath
sandbox/headless errors → set browser.headless=true and often browser.noSandbox=true on servers

Paste the tail + status output and we can pick the exact fix.

That log line is the key:

Error: Failed to start Chrome CDP on port 18800 for profile "openclaw".

So the Gateway is fine — it’s specifically failing to launch/attach to a Chromium-based browser with remote debugging (CDP).

On Ubuntu/Linux the #1 cause is Snap Chromium (or the “chromium” stub package that redirects to snap). Snap confinement tends to break CDP startup the way OpenClaw expects.

Fix (recommended): install a real Chrome binary + point OpenClaw to it

Install Google Chrome (deb):

wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo dpkg -i google-chrome-stable_current_amd64.deb
sudo apt --fix-broken install -y

Tell OpenClaw to use it + run headless (typical on servers):

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

Test:

openclaw browser --browser-profile openclaw --timeout 60000 start
openclaw browser --browser-profile openclaw --timeout 60000 open https://example.com
openclaw browser --browser-profile openclaw snapshot

Docs: https://docs.openclaw.ai/tools/browser-linux-troubleshooting

Quick check: is port 18800 already taken?

If it still fails, check for a port conflict:

ss -ltnp | grep 18800 || true
# or
lsof -nP -iTCP:18800 -sTCP:LISTEN || true

If you must keep Snap Chromium

Use “attach-only” mode + start Chromium manually (also in the doc). But I’d try the Chrome deb route first — it’s the least painful.

If you paste openclaw browser --browser-profile openclaw status output after setting executablePath, I can confirm it’s picking up the right browser.

That’s still the same root cause: the Gateway is reachable, but the managed browser profile (openclaw) can’t start a CDP-enabled Chromium:

Failed to start Chrome CDP on port 18800 for profile "openclaw"

Let’s narrow it down to “wrong browser picked” vs “browser binary missing/broken” vs “port conflict”.

1) Confirm what browser OpenClaw is trying to launch

Run and paste:

openclaw config get browser.executablePath
openclaw browser --browser-profile openclaw --timeout 60000 status

(That status output usually reveals the chosen browser path / profile details.)

2) Check if port 18800 is already in use

ss -ltnp | grep 18800 || true

If something is listening there, kill/stop it, or we’ll need to move the CDP port.

3) If you’re on Ubuntu: avoid Snap Chromium (common cause)

If chromium is snap-based, CDP startup often fails. Recommended fix is to install Google Chrome (.deb) and point OpenClaw to it:

wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo dpkg -i google-chrome-stable_current_amd64.deb
sudo apt --fix-broken install -y

openclaw config set browser.executablePath "/usr/bin/google-chrome-stable"
openclaw config set browser.headless true

openclaw config set browser.noSandbox true
openclaw gateway restart

Then test:

openclaw browser --browser-profile openclaw --timeout 60000 start
openclaw browser --browser-profile openclaw --timeout 60000 open https://example.com

Linux doc that matches your exact error: https://docs.openclaw.ai/tools/browser-linux-troubleshooting

4) If it still fails after Chrome install

Try launching Chrome manually to see the real stderr (missing libs, sandbox issue, etc.):

/usr/bin/google-chrome-stable --headless --no-sandbox --disable-gpu \
  --remote-debugging-port=18800 --user-data-dir=/tmp/oc-chrome \
  about:blank

If that prints an error, paste it.

Send the outputs from (1) + (2) and we can give you the exact “do X” fix (instead of guessing).

Nice — that output is the “everything works” happy path:

start succeeded (no timeout)
open https://example.com succeeded (tab id returned)
snapshot succeeded (DOM refs + content returned)

So your Chromium/CDP issue is resolved now.

If you changed something to get here (installed google-chrome-stable, set browser.executablePath, enabled headless/noSandbox, freed port 18800, etc.), that was the fix.

Two quick follow-ups so it stays stable:

Make sure the gateway service won’t break on Node upgrades (nvm warning)
Run:

openclaw doctor --repair

(Your gateway status explicitly warned about the systemd service using an nvm Node path.)

If this solved your thread, please mark the solution so Answer Overflow indexes it:
Right-click the solution message → Apps → ✅ Mark Solution.

If you want, paste openclaw config get browser and I’ll sanity-check the final browser settings for a headless server.

That message usually happens when the agent is not using the openclaw managed profile, but instead the default chrome extension-relay profile (or a mispointed CDP URL). On a headless server there’s no attached Chrome tab, so the relay endpoints can return a 404-ish “Requested resource not found”.

Since your CLI test works with --browser-profile openclaw, the fix is: make the agent default to that profile.

Set the default browser profile to `openclaw`

openclaw config set browser.defaultProfile openclaw
openclaw gateway restart

Sanity-check both profiles

openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile chrome status

openclaw should show it can start/has tabs.

chrome will only work if you installed the extension and “attached” a tab (not typical on servers).

If it still fails, grab the exact tool error

Run:

openclaw logs --follow

Then ask the agent to open https://dindrones.com, and paste the new browser.request ... errorMessage=... line. That will tell us whether it’s still picking chrome, or if there’s a CDP URL/port mismatch.

That status output tells me what’s happening:

openclaw profile = the managed, headless Chrome on CDP port 18800 (good for servers)
chrome profile = the extension relay on 18792 (only works if you have the browser extension attached to a tab — basically not a headless server thing)

So when your agent says “Requested resource not found”, it’s very likely it’s trying to use the chrome (relay) profile (or otherwise hitting the relay endpoint), which returns “nothing attached / not found”.

1) Make sure the agent defaults to the managed browser profile

Run:

openclaw config get browser.defaultProfile

If it’s chrome (or empty), set it:

openclaw config set browser.defaultProfile openclaw
openclaw gateway restart

2) Verify `dindrones.com` works via the managed profile (CLI)

This proves the browser itself can reach the site:

openclaw browser --browser-profile openclaw --timeout 60000 start
openclaw browser --browser-profile openclaw --timeout 60000 open https://dindrones.com
openclaw browser --browser-profile openclaw snapshot

If that works, then the problem is 100% profile selection in the agent (not networking).

3) Grab the exact error line from logs when the agent tries

Run:

openclaw logs --follow

Then ask the agent to browse again and paste the single line that looks like:

browser.request … errorMessage=…

That line will also usually reveal whether it used profile chrome vs openclaw (or if it tried target=sandbox, which is another common gotcha).

If you paste:

openclaw config get browser.defaultProfile
the result of the CLI open+snapshot to https://dindrones.com
the browser.request ... errorMessage=... line from logs

…I can tell you the exact one-line fix.

That tool call explains it: the agent is using profile: "chrome", which is the Chrome extension relay (cdpUrl: http://127.0.0.1:18792). That mode only works if you have the OpenClaw browser extension installed and a tab is manually “attached” (badge ON). On a headless server, there’s nothing to attach → the request tends to hang/time out / “resource not found”.

Fix: force the agent to use the managed profile

Set the default browser profile to the managed one:

openclaw config set browser.defaultProfile openclaw
openclaw gateway restart

Then try again with the agent (or test via CLI):

openclaw browser --browser-profile openclaw --timeout 60000 open https://google.com
openclaw browser --browser-profile openclaw snapshot

After this, even if the agent’s snapshot call omits profile, it’ll inherit openclaw as the default.

Alternative (only if you really want `profile: chrome`)

You must run a real Chrome/Brave with the extension installed on the same machine (or via a paired node), open a tab, and click the OpenClaw Browser Relay extension icon to attach it. Until a tab is attached, profile: chrome won’t work reliably.

If you want, paste openclaw config get browser.defaultProfile and I’ll confirm it’s set correctly.

Yep — that’s the core issue:

You did set up the managed browser (profile: openclaw) and it works (your CLI open + snapshot proves it).
But your agent is still explicitly calling the tool with profile: "chrome":

{ "action": "open", "profile": "chrome" }

chrome = extension relay (cdpUrl http://127.0.0.1:18792) and needs a manually attached tab. On a headless server it’ll fail/hang/“Requested resource not found”.

Setting browser.defaultProfile=openclaw only helps when the agent omits profile — it does not override an explicitly-chosen "chrome".

Fix: teach the agent to stop using `chrome`

Quick fix (just tell it once)

Send a message like:

“For browser tool calls, always use profile openclaw (managed browser). Never use profile chrome because there is no extension relay attached on this server.”

Then start a fresh session (/new) so it doesn’t keep repeating the old pattern.

Durable fix (recommended): put it in your system prompt

Add this to your workspace prompt file (usually ~/.openclaw/workspace/AGENTS.md or SOUL.md, depending on your setup):

## Browser tool rule (Linux server)
- Always use browser profile `openclaw`.
- Never use browser profile `chrome` (extension relay requires a manually attached tab).

Then:

openclaw gateway restart

and /new in chat.

Optional: find where “chrome” is being suggested

Sometimes a skill/prompt snippet hardcodes it:

grep -Rni '"profile": "chrome"\|profile: "chrome"\|browser-profile chrome' ~/.openclaw/workspace

If you paste the browser.request ... errorMessage=... log line from when the agent hangs, I can confirm it’s the relay endpoint and not something else.

#Search the web with agent using Chromium

1) Check whether the gateway is actually reachable

2) If RPC probe is failed: restart the gateway

3) If Config (cli) and Config (service) differ

4) Logs (most useful next artifact)

Notes

1) Re-run with a bigger timeout + watch logs

2) If this is a headless VPS, enable headless mode

3) Common Linux gotcha: Snap Chromium

4) Separate (but recommended): run Doctor

Fix (recommended): install a real Chrome binary + point OpenClaw to it

Quick check: is port 18800 already taken?

If you must keep Snap Chromium

1) Confirm what browser OpenClaw is trying to launch

2) Check if port 18800 is already in use

3) If you’re on Ubuntu: avoid Snap Chromium (common cause)

4) If it still fails after Chrome install

Set the default browser profile to openclaw

Sanity-check both profiles

If it still fails, grab the exact tool error

1) Make sure the agent defaults to the managed browser profile

2) Verify dindrones.com works via the managed profile (CLI)

3) Grab the exact error line from logs when the agent tries

Fix: force the agent to use the managed profile

Alternative (only if you really want profile: chrome)

Fix: teach the agent to stop using chrome

Quick fix (just tell it once)

Durable fix (recommended): put it in your system prompt

Optional: find where “chrome” is being suggested

2) If `RPC probe` is failed: restart the gateway

3) If `Config (cli)` and `Config (service)` differ

Set the default browser profile to `openclaw`

2) Verify `dindrones.com` works via the managed profile (CLI)

Alternative (only if you really want `profile: chrome`)

Fix: teach the agent to stop using `chrome`