Cowork cloud session: agent proxy returns 503 on WebSocket (wss) CONNECT while HTTPS to the same vendor works

This concerns a Cowork cloud session (claude.ai, remote sandbox), not the CLI, so the CLI-only template fields are not applicable.

Summary

In one long-running Cowork cloud container, every WebSocket connection to wss://connect.usw2.browserbase.com/ fails at the proxy with 503 Service Unavailable, while ordinary HTTPS to the same vendor from the same container succeeds. Other sessions on the same account, started later, are unaffected, which points at the container's own proxy route rather than the vendor or the credential.

Evidence, all from the same container, minutes apart

HTTPS to the vendor's API works:

curl -H "X-BB-API-Key: …" https://api.browserbase.com/v1/projects   ->  200

The WebSocket does not, on every attempt over roughly three hours:

BrowserType.connect_over_cdp: WebSocket error: wss://connect.usw2.browserbase.com/ 503 Service Unavailable
upstream connect error or disconnect/reset before headers. retried and the latest reset reason: connection timeout
  <ws unexpected response> wss://connect.usw2.browserbase.com/ 503 Service Unavailable
  <ws disconnected> code=1006

The 503 body is the proxy's own (upstream connect error or disconnect/reset before headers), not the vendor's.

GET $HTTPS_PROXY/__agentproxy/status reports the proxy healthy and unrestricted at the time of failure: enabled: true, selective: false, toolScoped: false, bundleCoversEveryHost: true, and recentRelayFailures: [] — so the refusals are not recorded anywhere a session can see them.

Why it matters

Browser automation over CDP is the only route this account has to several of its own logged-in services, so a container in this state silently loses every browser-backed capability while all HTTPS checks report healthy. There is no signal distinguishing it from a vendor outage: the session's honest conclusion was "the vendor is down", which was wrong, and it took an API call plus a proxy-status read to tell the two apart.

Asks

1. WebSocket CONNECT should either be proxied on the same terms as HTTPS to the same host, or refused with a message naming the policy, as host-blocked CONNECTs are today.
2. A relay failure of this kind should appear in __agentproxy/status (recentRelayFailures stayed empty throughout), so a session can tell a container-side route failure from a vendor outage without guessing.

Trace the agent proxy's HTTPS_PROXY handling, WebSocket CONNECT path, and GET $HTTPS_PROXY/__agentproxy/status endpoint; compare the failing connect_over_cdp case with the successful curl request. Done means WebSocket CONNECT follows the stated policy or reports it clearly, and relay failures appear in recentRelayFailures.