fix(browser): resolve HTTP CDP URLs

[MagMueller]

Summary

• treat BU_CDP_URL=http://... as a DevTools HTTP endpoint and resolve its WebSocket URL through /json/version
• retry discovery within the caller’s existing connection timeout so a browser that is still starting can become ready
• surface HTTP 403 as an immediate remote-debugging permission error
• preserve BU_CDP_URL=ws://... compatibility and keep BU_CDP_WS as the highest-priority direct WebSocket setting

Previously an HTTP BU_CDP_URL was passed directly to new WebSocket, which attempted an upgrade on the HTTP root instead of querying /json/version. This matches the public browser-harness endpoint contract.

Validation

• bun test in packages/bcode-browser: 16 pass, 8 environment-gated skips
• deterministic tests cover HTTP discovery, cold-start retries, permission denial, WebSocket compatibility, and env precedence
• package typecheck and root filtered typecheck: pass
• bunx oxlint packages/bcode-browser/test/connect-env.test.ts: clean

---

Summary by cubic

Fixes connection to Chrome when BU_CDP_URL is an HTTP DevTools endpoint by resolving its WebSocket URL via /json/version. Uses a single connection deadline for discovery and WebSocket open, adds retries until the deadline, and clearer 403 permission errors, while keeping BU_CDP_WS priority and BU_CDP_URL WebSocket compatibility.

• Bug Fixes
  • Resolve HTTP BU_CDP_URL through /json/version to obtain webSocketDebuggerUrl.
  • Keep discovery within the caller’s deadline with retries; WebSocket open uses remaining time.
  • Surface HTTP 403 as an immediate remote-debugging permission error.
  • Preserve precedence: BU_CDP_WS over BU_CDP_URL; accept WebSocket values in BU_CDP_URL.

^{Written for commit d3e7b76. Summary will update on new commits.}

[cubic-dev-ai]

All reported issues were addressed across 2 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[Alezander9]

Thanks Magnus — closing this one as not-needed rather than wrong.

No consumer

BU_CDP_URL is set nowhere in cloud. The v4 worker sets BU_CDP_WS, and it already does this exact /json/version resolution itself before launching bcode — resolve_cdp_ws_url at backend/sandboxes/v4-worker/app.py:238-266, fed by fetch_browser_cdp at app.py:221-235. There's a mirror of it control-plane side at backend/control_plane/api/v4/services.py:917-940 for agent-created browsers. So this adds a second implementation of a resolution step that already works one layer up, for a variable nothing sets.

It forks a documented alias

skills/browser-execute/SKILL.md:95 currently tells the agent:

If BU_CDP_WS (or its alias BU_CDP_URL) is set in the environment, session.connect() with no args connects to that endpoint directly.

This PR gives the two variables different semantics without touching that line, so the skill the agent actually reads becomes wrong. Two env vars that look like aliases but resolve differently is a bad surface for a model to reason about.

The cold-start retry is speculative

The retry-until-deadline loop is for "a browser that is still starting". In v4 the browser is provisioned and long-polled to readiness before bcode launches (backend/control_plane/api/v4/router.py:316-337), so bcode never observes a cold start. If some other harness needs it, that's the justification to state.

If we do want this later

The shape that fits our conventions is one variable, not two: BU_CDP_WS accepts ws:// or http:// and resolves when it's HTTP, and BU_CDP_URL is deleted outright. We prefer complete removal of the old over keeping a compatibility alias around.

Happy to take that version if a real caller shows up.