openclaw - 💡(How to fix) Fix [Bug]: Browser tool times out in Docker even though Playwright Chromium launches successfully manually [1 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Body: I’m running OpenClaw 2026.4.1 in Docker on a VPS (Ubuntu 22 host, Debian 12/bookworm container). Goal is to use the browser tool via WhatsApp.

What I observed:

• browser tool with profile:"host-chrome" failed because remote CDP ws://172.18.0.1:9222 was unreachable
• installed browser support in the container image and rebuilt
• Playwright browsers are now present under /home/node/.cache/ms-playwright
• manual Playwright launch inside the container works successfully
• OpenClaw gateway starts normally
• browser control server starts
• browser control service reports ready
• but browser tool open still times out

Evidence:

• manual Playwright test inside container:
  • launches Chromium
  • opens https://example.com
  • returns title Example Domain
• gateway logs show:
  • [browser/server] Browser control listening
  • [browser/service] Browser control service ready (profiles=3)
  • then browser tool fails with timeout
• browser config originally had:
  • defaultProfile: "host-chrome"
  • cdpUrl: "ws://172.18.0.1:9222"
• removed that default/broken host profile and restarted
• timeout still persists

Docker/browser details:

• shm_size: 2gb
• cap_add: [SYS_ADMIN]
• security_opt: [seccomp:unconfined]
• Playwright install path exists and contains Chromium
• manual Playwright launch confirms environment is healthy

Conclusion: This looks like an OpenClaw browser wrapper/service issue rather than a missing browser dependency or container hardening issue.

If helpful, I can also provide:

• compose file
• Dockerfile
• exact manual Playwright command that succeeds

Steps to reproduce

Repro summary

Environment:

• OpenClaw 2026.4.1
• VPS host: Ubuntu 22
• Docker container: Debian 12 (bookworm)
• Channel used to trigger: WhatsApp
• Goal: use built-in browser tool from chat

Initial state

• browser.defaultProfile was set to host-chrome
• host-chrome pointed to ws://172.18.0.1:9222
• that CDP endpoint was not reachable

What we changed

1. Added browser support to the Docker image
2. Rebuilt and restarted the stack
3. Confirmed Playwright browsers installed
4. Confirmed manual Playwright launch works
5. Removed broken host-chrome default/profile from config
6. Restarted again
7. Browser tool still times out

Exact symptoms

• Browser logs show:
  • browser control server starts
  • browser control service becomes ready
• Then tool call:
  • browser.open(url=https://example.com, profile=openclaw)
• Result:
  • timeout
  • message says to restart gateway, but restart does not fix it

Proof the environment itself works Inside the container, this succeeds:

bash docker exec -it openclaw-openclaw-gateway-1 bash -lc 'node -e "(async()=>{const { chromium } = require("playwright-core"); const browser = await chromium.launch({headless:true}); console.log("LAUNCHED"); const page = await browser.newPage(); await page.goto("https://example.com\", {waitUntil:"domcontentloaded", timeout:30000}); console.log(await page.title()); await browser.close();})().catch(err=>{console.error("PWERR_START"); console.error(err && (err.stack || err)); process.exit(1);})"'

Output: text LAUNCHED Example Domain

Proof browser assets are present Inside container: bash docker exec -it openclaw-openclaw-gateway-1 bash -lc 'ls -R /home/node/.cache/ms-playwright | head -100'

Shows:

• chromium-1208
• chromium_headless_shell-1208
• ffmpeg-1011

OpenClaw logs around failure Relevant lines:

• [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
• [browser/service] Browser control service ready (profiles=3)
• then:
• [tools] browser failed: timed out ... raw_params={"action":"open","target":"host","profile":"openclaw","url":"https://example.com"}

Config note Original browser config was:

json { "enabled": true, "defaultProfile": "host-chrome", "profiles": { "host-chrome": { "cdpUrl": "ws://172.18.0.1:9222", "color": "#FF6600" } } }

We removed defaultProfile and removed host-chrome, restarted, retried, and the timeout still happens.

Conclusion This appears reproducible as:

• Docker deployment
• Playwright Chromium installed and manually working
• OpenClaw browser service starts
• browser tool open still times out

If you want, I can also compress this into an even tighter 5-bullet repro version for GitHub comments

Expected behavior

Should allow connection via browser tool.

Actual behavior

It doesn- connect.

OpenClaw version

April 1 2026.

Operating system

Ubuntu 22

Install method

No response

Model

gpt 5.4 codex

Provider / routing chain

rovider / routing chain Trigger path: - User sends command via WhatsApp - WhatsApp message reaches OpenClaw gateway - Assistant receives the message and calls the built-in browser tool - Tool invocation is: - action: open - target: host - profile: openclaw - url: https://example.com Observed internal chain from logs: - WhatsApp inbound handled by gateway - OpenClaw browser tool routes into browser control service - browser control service starts successfully - browser service reports ready - then the browser tool request times out before completing page open Relevant log sequence: - [whatsapp] Inbound message ... - [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token) - [browser/service] Browser control service ready (profiles=3) - [tools] browser failed: timed out ... raw_params={"action":"open","target":"host","profile":"openclaw","url":"https://example.com"} So the routing chain is: WhatsApp → OpenClaw gateway → assistant tool call → browser tool → browser control server/service → timeout Important clarification: - This is not going through external browser SaaS or a third-party provider - It appears to be entirely local to the OpenClaw gateway/container - Manual in-container Playwright works, so the failure is likely between OpenClaw’s browser tool layer and its browser control/launch path, not upstream of the gateway and not in Chromium itself

Additional provider/model setup details

rovider / routing chain

Trigger path:

• User sends command via WhatsApp
• WhatsApp message reaches OpenClaw gateway
• Assistant receives the message and calls the built-in browser tool
• Tool invocation is:
  • action: open
  • target: host
  • profile: openclaw
  • url: https://example.com

Observed internal chain from logs:

• WhatsApp inbound handled by gateway
• OpenClaw browser tool routes into browser control service
• browser control service starts successfully
• browser service reports ready
• then the browser tool request times out before completing page open

Relevant log sequence:

• [whatsapp] Inbound message ...
• [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
• [browser/service] Browser control service ready (profiles=3)
• [tools] browser failed: timed out ... raw_params={"action":"open","target":"host","profile":"openclaw","url":"https://example.com"}

So the routing chain is:

WhatsApp → OpenClaw gateway → assistant tool call → browser tool → browser control server/service → timeout

Important clarification:

• This is not going through external browser SaaS or a third-party provider
• It appears to be entirely local to the OpenClaw gateway/container
• Manual in-container Playwright works, so the failure is likely between OpenClaw’s browser tool layer and its browser control/launch path, not upstream of the gateway and not in Chromium itself

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

rovider / routing chain

Trigger path:

• User sends command via WhatsApp
• WhatsApp message reaches OpenClaw gateway
• Assistant receives the message and calls the built-in browser tool
• Tool invocation is:
  • action: open
  • target: host
  • profile: openclaw
  • url: https://example.com

Observed internal chain from logs:

• WhatsApp inbound handled by gateway
• OpenClaw browser tool routes into browser control service
• browser control service starts successfully
• browser service reports ready
• then the browser tool request times out before completing page open

Relevant log sequence:

• [whatsapp] Inbound message ...
• [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
• [browser/service] Browser control service ready (profiles=3)
• [tools] browser failed: timed out ... raw_params={"action":"open","target":"host","profile":"openclaw","url":"https://example.com"}

So the routing chain is:

WhatsApp → OpenClaw gateway → assistant tool call → browser tool → browser control server/service → timeout

Important clarification:

• This is not going through external browser SaaS or a third-party provider
• It appears to be entirely local to the OpenClaw gateway/container
• Manual in-container Playwright works, so the failure is likely between OpenClaw’s browser tool layer and its browser control/launch path, not upstream of the gateway and not in Chromium itself