Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In a WSL OpenClaw -> Windows Chrome remote CDP setup, openclaw browser status and openclaw browser tabs can false-negative even though the remote CDP endpoint is healthy.

Validated setup:

• browser.defaultProfile=remote
• cdpUrl=http://172.29.128.1:9223
• attach-only remote CDP
• no explicit browser.ssrfPolicy configured

Observed behavior:

• openclaw browser status reports running: false
• openclaw browser tabs returns empty / No tabs (browser closed or no targets).

At the same time:

• raw GET /json/version succeeds
• raw GET /json/list shows many live page targets
• Playwright connectOverCDP() succeeds
• direct websocket health (Browser.getVersion) succeeds

Validated root cause: browser.ssrfPolicy unset currently resolves to {} instead of undefined / null, and that empty object is still treated as an active SSRF policy in the strict CDP readiness path.

Steps to reproduce

1. Run OpenClaw in WSL.
2. Run Windows Chrome with remote debugging enabled.
3. Configure OpenClaw browser integration to use:
   • browser.defaultProfile=remote
   • cdpUrl=http://172.29.128.1:9223
4. Leave browser.ssrfPolicy unset.
5. Make sure Chrome already has normal live tabs open.
6. From WSL, verify:
   • http://172.29.128.1:9223/json/version
   • http://172.29.128.1:9223/json/list
7. Run:
   • openclaw browser status
   • openclaw browser tabs

Optional confirmation: 8. Attach with Playwright via connectOverCDP() and verify pages can be enumerated.

Expected behavior

If browser.ssrfPolicy is not configured, the remote CDP readiness path should not behave as if an SSRF policy is active.

For a healthy configured endpoint like http://172.29.128.1:9223, OpenClaw should report:

• running: true
• normal live tabs

Actual behavior

OpenClaw reports:

• openclaw browser status -> running: false
• openclaw browser tabs -> empty / No tabs (browser closed or no targets).

But the endpoint is actually healthy:

• raw /json/version succeeds
• raw /json/list returns many live page targets
• Playwright connectOverCDP() succeeds
• direct websocket Browser.getVersion succeeds

Confirmed failing chain:

• status / tabs
• -> profileCtx.isReachable(...)
• -> isChromeCdpReady(...)
• -> getChromeWebSocketUrl(...)
• -> assertCdpEndpointAllowed(cdpUrl, ssrfPolicy)
• -> BrowserCdpEndpointBlockedError: browser endpoint blocked by policy

Confirmed config/guard mismatch:

• resolveBrowserSsrFPolicy(cfg) returns {} when browser.ssrfPolicy is unset
• assertCdpEndpointAllowed(cdpUrl, ssrfPolicy) only skips checks when !ssrfPolicy

Because {} is truthy, the strict remote CDP readiness path still applies endpoint SSRF validation to the configured private bridge endpoint.

OpenClaw version

2026.4.11

Operating system

OpenClaw host: WSL on Windows Remote browser host: Windows Chrome via remote debugging

Install method

npm global install

Model

Not model-specific. This appears to be in browser/CDP readiness logic, not model execution.

Provider / routing chain

Not provider/model routing related. Relevant runtime path: WSL OpenClaw -> Windows Chrome remote CDP

Additional provider/model setup details

None. This issue appears independent of model/provider configuration.

Logs, screenshots, and evidence

Available evidence from local validation:
- raw `GET /json/version` succeeded
- raw `GET /json/list` showed many live `type=page` targets
- Playwright `connectOverCDP()` succeeded and enumerated pages
- direct websocket connect + `Browser.getVersion` succeeded
- exact failing chain was confirmed during local runtime instrumentation

Validated minimal local fix:
- in `config-C4Yha3Le.js`
- change the no-config case in `resolveBrowserSsrFPolicy(cfg)`
- from `return {}`
- to `return undefined` (or `null`)

After restarting the gateway:
- `openclaw browser status` changed to `running: true`
- `openclaw browser tabs` returned the normal live tab list

Debug instrumentation was later rolled back. Only the functional resolver patch was kept during validation.

Impact and severity

Medium to high for remote-CDP users.

This can make a healthy remote browser integration appear broken, because:

• status reports running: false
• tabs returns empty
• users may assume the remote Chrome target or OpenClaw browser integration is fundamentally broken

The bug is especially misleading because raw CDP, Playwright, and websocket health can all be healthy at the same time.

Additional information

Suggested upstream fix:

Preferred:

• make resolveBrowserSsrFPolicy() return undefined or null when browser SSRF policy is unset

Alternative:

• make CDP endpoint guards treat an empty policy object as disabled

I think the first option is cleaner because it preserves the meaning of “no browser SSRF policy configured”.

I have a minimal local fix validated and can open a PR if this direction looks right.