← Back to PRs

#17760: fix(browser): rewrite 0.0.0.0 and [::] wildcard addresses in CDP WebSocket URLs

by joeharouni open 2026-02-16 05:02 View on GitHub →
stale size: XS
## 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