Cowork cloud egress: WebSocket (wss) hosts refused while ordinary HTTPS to the same service is allowed

Surface: Claude Cowork on the web, cloud sessions, Max plan (individual).
Setting: Settings > Capabilities > Allow network egress ON, Domain allowlist = All domains, unchanged.

Since the 10 Sep egress regression on this account (#34690) was partially restored on 14 Sep, ordinary HTTPS works again but WebSocket endpoints are still refused by the gateway, including for a service whose HTTPS API is allowed in the same session.

Measured 2026-09-14, 17:2x UTC, one session:

https://api.browserbase.com/          404   (reaches the origin, allowed)
wss://connect.usw2.browserbase.com/   403   Host not in allowlist: connect.usw2.browserbase.com.
                                            Add this host to your network egress settings to allow access.

The Playwright form of the same failure:

BrowserType.connect_over_cdp: WebSocket error: wss://connect.usw2.browserbase.com/ 403 Forbidden
  - <ws unexpected response> ... 403 Forbidden
  - <ws connect error> WebSocket was closed before the connection was established

Expected: with the allowlist set to All domains, a wss host is reachable like any other.

Actual: the gateway answers 403 with "Host not in allowlist", naming a host the account's setting does not exclude, while plain HTTPS to arbitrary hosts (www.google.com, example.com, api.openai.com, cdn.jsdelivr.net) succeeds from the same session.

Impact: any browser-automation or realtime service driven from a cloud session is dead, because the control channel is a WebSocket even when the REST API is reachable. Sessions can create a remote browser and then cannot attach to it.

Related, same account, same window: pypi.org and registry.npmjs.org return 403 from that session while arbitrary web hosts succeed, which inverts the usual symptom and breaks pip install in a cloud session. Details on #34690 (comment 5667492876).