openclaw - 💡(How to fix) Fix [Bug]: Remote CDP profiles (Browserbase) lose session between commands — multi-step workflows impossible [1 participants]

Description

When using Browserbase via a remote CDP profile, the gateway creates a new WebSocket connection for each CLI command. Since Browserbase creates a new browser session per WebSocket connection, the browser state (loaded pages, cookies, DOM) is lost between commands.

This makes multi-step workflows impossible:

openclaw browser --browser-profile browserbase navigate "https://example.com"  # ✅ Works
openclaw browser --browser-profile browserbase snapshot                        # ❌ "Remote CDP not reachable"

Root Cause

The gateway does not hold the WebSocket connection open between CLI invocations. Each command:

1. Opens a new WebSocket to wss://connect.browserbase.com?apiKey=...
2. Browserbase spins up a fresh browser session
3. Executes the command
4. WebSocket closes when command completes
5. Browserbase destroys the session

On the next command, step 1 creates an entirely new session with a blank browser. On free tiers (1 concurrent session), it's worse: the old session hasn't been cleaned up yet, so the new connection is blocked by the concurrent session limit, causing immediate "not reachable" errors.

Evidence

Tested on OpenClaw 2026.3.28 with Browserbase (wss://connect.browserbase.com).

Raw WebSocket test confirms the provider works fine:

CONNECTED in 1116 ms
CDP OK in 7147 ms  (Browser.getVersion returned Chrome/146.0.7680.165)

Gateway behavior observed via logs:

• navigate succeeds (new session created, page loaded)
• snapshot 148ms later fails with "Remote CDP not reachable" (doesn't even attempt the 10s handshake timeout, just detects dead connection)
• Browserbase API shows multiple zombie sessions accumulating from failed reconnection attempts

Additional findings:

• remoteCdpHandshakeTimeoutMs config was needed (Browserbase cold start takes ~5-7s), but even with correct timeouts, multi-step workflows fail due to session non-persistence
• Free tier concurrent session limit (1) causes cascading failures as zombie sessions block new connections
• Local profiles (localhost CDP) are unaffected since Chrome stays running persistently

Expected Behavior

For remote CDP profiles, the gateway should hold the WebSocket connection open after browser start (or first command) and reuse it for subsequent commands until browser stop is called or the session times out. This matches how local profiles work (persistent Chrome process on a fixed port).

Suggested Implementation

1. On first connect to a remote CDP URL, keep the WebSocket alive in the gateway's browser subsystem
2. Reuse the existing connection for subsequent commands on the same profile
3. Implement reconnection logic if the WebSocket drops (with backoff)
4. On browser stop, cleanly close the WebSocket and release the provider session

Related

• #4378 — Identical issue reported for Browserless.io (closed without fix during triage). The Browserless CEO offered to collaborate on a fix.
• #15989 — "tab not found" after reconnection on remote CDP
• #23427 — CDP connection silently dies after idle period
• #29431 — Browser relay loses CDP connection on navigation

Environment

• OpenClaw: 2026.3.28 (f9b1079)
• Provider: Browserbase (free tier, 1 concurrent session)
• OS: Linux 6.8.0-106-generic (x64)
• Node: v22.22.1