[Windows][Remote Control] Network-path-dependent 503 errors: works on mobile hotspot, fails on residential ISP over both IPv4 and IPv6

What version of the Codex App are you using (From “About Codex” dialog)?

26.903.61454

What subscription do you have?

Plus

What platform is your computer?

Windows 11

What issue are you seeing?

Codex Desktop Remote Control becomes unavailable on my residential ISP connection, while it works normally on the same PC when using a mobile hotspot.

When connected through my residential ISP, Codex repeatedly fails to connect to:

wss://chatgpt.com/backend-api/wham/remote/control/server

The connection attempts return:

HTTP 503 Service Unavailable
upstream connect error or disconnect/reset before headers.
reset reason: connection termination

The problem affects both IPv4 and IPv6.

When I switch the same PC to a mobile hotspot, without restarting Codex or changing any settings, Remote Control automatically becomes available again and works normally.

This behavior is also reproducible outside Codex using curl against the Remote Control WebSocket endpoint.

What steps can reproduce the bug?

1. Start Codex Desktop on Windows with Remote Control already enrolled.

2. Connect the PC to my residential Internet connection (Claro/Virtua, Brazil).

3. Open Codex Remote Control.

   • "Allow connections" becomes unavailable/disabled.
   • The mobile device can still see existing activities, but cannot open/control them.
   • Codex repeatedly attempts to reconnect and receives HTTP 503 errors.

4. Without restarting Codex, switch the PC from the residential network to a mobile hotspot.

5. Remote Control automatically recovers:

   • "Allow connections" becomes enabled again.
   • The mobile device can access the Codex sessions.
   • The connection remains stable.

6. Without restarting Codex, switch the PC back to the residential network.

7. Remote Control fails again and the reconnect attempts return HTTP 503.

8. Switch back to the mobile hotspot again.

   • Remote Control automatically starts working again.

The issue can also be reproduced outside Codex with:

curl.exe -4 -i --http1.1 "https://chatgpt.com/backend-api/wham/remote/control/server" ^
-H "Connection: Upgrade" ^
-H "Upgrade: websocket" ^
-H "Sec-WebSocket-Version: 13" ^
-H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ=="

Mobile hotspot result:
HTTP 400 Bad Request
{"detail":"Missing required websocket headers"}

Residential ISP result:
HTTP 503 Service Unavailable
upstream connect error or disconnect/reset before headers.
reset reason: connection termination

The same residential test forced over IPv6 also returns HTTP 503.

What is the expected behavior?

Remote Control should connect and remain available on a normal Internet connection as long as chatgpt.com is reachable over HTTPS/WebSocket.

Changing from a mobile hotspot to a residential ISP should not cause the Remote Control backend connection to fail with HTTP 503.

The Remote Control service should behave consistently regardless of the source network.

Additional information

Environment:

• OS: Windows
• Codex Desktop package version: 26.903.8094.0
• Codex app-server client version reported in logs: 26.903.61454
• Remote Control enrollment remains present during the failure:
  • has_enrollment=true
  • server_id present
  • environment_id present

No IDs, tokens, cookies, server IDs, environment IDs or installation IDs are included here.

Residential ISP:
Claro / Virtua, Brazil

Residential network:

• Router WAN IPv4: 100.66.2.221 (CGNAT)
• Public IPv4: 181.217.89.90
• Native IPv6 available
• IPv4 and IPv6 traceroutes to chatgpt.com complete successfully
• TCP/443, DNS and TLS connectivity are working normally

Cloudflare trace on residential IPv4:

• colo=GRU
• sliver=050-tier1
• tls=TLSv1.3

Cloudflare trace on residential IPv6:

• colo=GRU
• sliver=050-tier1
• tls=TLSv1.3

Mobile hotspot:

• Public IPv4: 189.93.3.188
• colo=GRU
• sliver=005-tier1
• tls=TLSv1.3

Example CF-RAY when the hotspot reaches the Remote Control backend:
a38a77d55828add3-GRU

Response:
HTTP 400
{"detail":"Missing required websocket headers"}

Example CF-RAY on the residential ISP failure:
a38a790d9cf41dd0-GRU

Response:
HTTP 503
upstream connect error or disconnect/reset before headers.
reset reason: connection termination

Codex logs also captured the transition from a working session to failure:

remote control websocket reader disconnected
failed to read from websocket
IO error: An existing connection was forcibly closed by the remote host
(os error 10054)

followed by:

previous_status=Connected
next_status=Connecting

and repeated reconnect attempts returning HTTP 503.

At the same time, regular Codex WebSocket traffic to:

wss://chatgpt.com/backend-api/codex/responses

continues to successfully upgrade to WebSocket.

Therefore, WebSockets in general are not blocked. The failure appears specific to the Remote Control endpoint.

The strongest A/B/A reproduction is:

mobile hotspot -> Remote Control works
residential ISP -> Remote Control fails with 503
mobile hotspot -> Remote Control works again

No Codex restart or configuration change is performed between these network switches.

This suggests a source-network/path-dependent routing, backend selection, load-balancing, or upstream-affinity problem affecting the Remote Control service.

Start at the Remote Control WebSocket endpoint, wss://chatgpt.com/backend-api/wham/remote/control/server, and reproduce the residential-versus-hotspot behavior with the supplied curl command. Compare the 503 response, WebSocket logs, and successful /backend-api/codex/responses upgrade; done means Remote Control connects consistently across both network paths.