#17760: fix(browser): rewrite 0.0.0.0 and [::] wildcard addresses in CDP WebSocket URLs
stale
size: XS
Cluster:
Browser Enhancements and Fixes
## Summary
When a containerized browser (e.g. [browserless](https://github.com/browserless/browserless)) reports its `webSocketDebuggerUrl` in `/json/version`, Chrome binds to all interfaces and returns addresses like `ws://0.0.0.0:3000/devtools/browser/...` or `ws://[::]:3000/...`. These are wildcard bind addresses, not routable endpoints.
`normalizeCdpWsUrl` already rewrites loopback addresses (`127.0.0.1`, `::1`, `localhost`) to the external `cdpUrl` host and port, but it does not handle `0.0.0.0` or `[::]`. This causes OpenClaw to attempt a literal WebSocket connection to `ws://0.0.0.0:3000`, which fails.
## Changes
- Treat `0.0.0.0` and `[::]` as wildcard bind addresses that need the same host/port/protocol rewriting as loopback addresses
- Added two test cases covering both wildcard forms
## Testing
- All existing tests pass (`pnpm test` — 8/8)
- `pnpm check` passes (formatting, type checking, linting)
- Verified end-to-end with a remote browserless instance reporting `ws://0.0.0.0:3000` — after the fix, the URL is correctly rewritten to the external CDP host and port
Fixes #17752
---
> **AI Disclosure**: This PR was developed with AI assistance (Claude). The author understands the changes, has verified them locally against a live browserless integration, and all tests pass.
<!-- greptile_comment -->
<h3>Greptile Summary</h3>
Clean, well-scoped bug fix that extends `normalizeCdpWsUrl` to handle wildcard bind addresses (`0.0.0.0` and `[::]`) reported by containerized browsers in their `webSocketDebuggerUrl`. These addresses are now rewritten to the external CDP host/port, matching the existing behavior for loopback addresses.
- Adds `isWildcardBind` check for `0.0.0.0` and `[::]` in `normalizeCdpWsUrl`, integrated into the existing loopback rewriting condition
- Two new test cases cover both IPv4 and IPv6 wildcard forms with host, port, query param, and protocol rewriting verification
- No logic issues found; the implementation correctly aligns with `isLoopbackHost` which explicitly excludes wildcard addresses from loopback detection
<h3>Confidence Score: 5/5</h3>
- This PR is safe to merge — it's a minimal, well-tested fix that extends existing rewriting logic to cover two additional hostname patterns.
- The change is small (one new boolean, one expanded condition) and purely additive — it cannot break existing loopback rewriting behavior. The new wildcard detection logic is correct for Node.js URL parsing semantics (verified in the previous thread). Both wildcard forms have dedicated test coverage. The fix addresses a real bug (literal connection to ws://0.0.0.0) confirmed by end-to-end testing with a live browserless instance.
- No files require special attention.
<sub>Last reviewed commit: fb1382d</sub>
<!-- greptile_other_comments_section -->
<!-- /greptile_comment -->
Most Similar PRs
#13568: Fix browser (OpenClaw-managed) launch fail by binding remote debugg...
by singlag · 2026-02-10
77.6%
#15595: fix(browser): avoid local port conflicts for remote cdp
by TsekaLuk · 2026-02-13
76.9%
#13325: (feat)Normalize to pass WebSocket CDP URLs for Browser
by snekkenull · 2026-02-10
76.6%
#5278: fix(browser): prevent DNS rebinding in extension relay HTTP endpoints
by webvijayi · 2026-01-31
75.9%
#9020: fix(browser): skip port ownership and WS reachability checks for re...
by yepack · 2026-02-04
75.3%
#16905: fix: prevent excessive Chrome tab creation on startup
by MisterGuy420 · 2026-02-15
74.0%
#14944: fix(browser): prefer openclaw profile in headless/noSandbox environ...
by BenediktSchackenberg · 2026-02-12
73.4%
#22110: fix(tools): prefer loopback for internal tool-to-gateway RPC calls
by pierreeurope · 2026-02-20
72.9%
#22952: fix(browser): suggest remote profile when local Chrome is not insta...
by dashed · 2026-02-21
72.9%
#8303: fix(browser): enable downloads via CDP Browser.setDownloadBehavior
by gavinbmoore · 2026-02-03
72.5%