From 8170df912792d9894f0bf1b7d1dc507758afc18b Mon Sep 17 00:00:00 2001 From: Quratulain-bilal Date: Sat, 25 Apr 2026 23:59:53 +0500 Subject: [PATCH] docs(browser): document local startup timeout bounds (#71672) * docs(browser): document local startup timeout bounds The new browser.localLaunchTimeoutMs and browser.localCdpReadyTimeoutMs options are clamped to MAX_BROWSER_STARTUP_TIMEOUT_MS (120000 ms) by normalizeStartupTimeoutMs in extensions/browser/src/browser/config.ts, and zero/negative/non-finite values fall back to the defaults. Without this in the configuration reference, users setting a higher value see no error and silently get the 120 s ceiling, or set 0 expecting 'no timeout' and silently get the default. * docs(browser): clarify startup timeout validation --------- Co-authored-by: Peter Steinberger --- docs/gateway/configuration-reference.md | 3 ++- docs/tools/browser-linux-troubleshooting.md | 4 ++-- docs/tools/browser.md | 3 ++- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/docs/gateway/configuration-reference.md b/docs/gateway/configuration-reference.md index 614ea8ae3f6..978e3bf75f1 100644 --- a/docs/gateway/configuration-reference.md +++ b/docs/gateway/configuration-reference.md @@ -280,7 +280,8 @@ See [Plugins](/tools/plugin). - Local managed profiles use `browser.localLaunchTimeoutMs` for Chrome CDP HTTP discovery after process start and `browser.localCdpReadyTimeoutMs` for post-launch CDP websocket readiness. Raise them on slower hosts where Chrome - starts successfully but readiness checks race startup. + starts successfully but readiness checks race startup. Both values must be + positive integers up to `120000` ms; invalid config values are rejected. - Auto-detect order: default browser if Chromium-based → Chrome → Brave → Edge → Chromium → Chrome Canary. - `browser.executablePath` accepts `~` for your OS home directory. - Control service: loopback only (port derived from `gateway.port`, default `18791`). diff --git a/docs/tools/browser-linux-troubleshooting.md b/docs/tools/browser-linux-troubleshooting.md index 0b9a9767cce..16af61fad96 100644 --- a/docs/tools/browser-linux-troubleshooting.md +++ b/docs/tools/browser-linux-troubleshooting.md @@ -140,8 +140,8 @@ curl -s http://127.0.0.1:18791/tabs On Raspberry Pi, older VPS hosts, or slow storage, raise `browser.localLaunchTimeoutMs` when Chrome needs more time to expose its CDP HTTP endpoint. Raise `browser.localCdpReadyTimeoutMs` when launch succeeds but -`openclaw browser start` still reports `not reachable after start`. Values are -capped at 120000 ms. +`openclaw browser start` still reports `not reachable after start`. Values must +be positive integers up to `120000` ms; invalid config values are rejected. ### Problem: "No Chrome tabs found for profile=\"user\"" diff --git a/docs/tools/browser.md b/docs/tools/browser.md index f8ec17d5df2..dfa0f3d9e74 100644 --- a/docs/tools/browser.md +++ b/docs/tools/browser.md @@ -200,7 +200,8 @@ Browser settings live in `~/.openclaw/openclaw.json`. process to expose its CDP HTTP endpoint. `localCdpReadyTimeoutMs` is the follow-up budget for CDP websocket readiness after the process is discovered. Raise these on Raspberry Pi, low-end VPS, or older hardware where Chromium - starts slowly. Values are capped at 120000 ms. + starts slowly. Values must be positive integers up to `120000` ms; invalid + config values are rejected. - `actionTimeoutMs` is the default budget for browser `act` requests when the caller does not pass `timeoutMs`. The client transport adds a small slack window so long waits can finish instead of timing out at the HTTP boundary. - `tabCleanup` is best-effort cleanup for tabs opened by primary-agent browser sessions. Subagent, cron, and ACP lifecycle cleanup still closes their explicit tracked tabs at session end; primary sessions keep active tabs reusable, then close idle or excess tracked tabs in the background.