[Remote][Windows/Android] Pairing succeeds and host WebSocket is Connected, but Android attach immediately closes with `Transport unavailable`

Summary

Codex Remote on Android can successfully pair with a Windows host, and the Windows host successfully creates a fresh Remote enrollment and reaches Connected on the Remote WebSocket, but the Android client cannot attach to the host. The mobile UI reports Transport unavailable, no chats are accessible, and the Windows logs show repeated Remote client connections being immediately closed.

This began after Remote had previously worked.

Environment

• Host: Windows
• ChatGPT Desktop package: OpenAI.ChatGPT-Desktop 1.2026.190.0
• Codex Desktop client reported in logs: 26.818.31338
• Remote controller: ChatGPT Android app
• Remote pairing: succeeds
• Mobile error: Transport unavailable

Current behavior

The desktop host registers successfully with Remote:

remote control websocket status changed previous_status=Connecting next_status=Connected
connected to app-server remote control websocket

A completely fresh Remote identity was generated and persisted successfully:

has_enrollment=true
server_id=Some("srv_e_...")
environment_id=Some("env_e_...")

However, when the Android client tries to connect, the desktop logs show repeated immediate closures such as:

forwarding remote control connection closed transport event connection_id=ConnectionId(3)
forwarding remote control connection closed transport event connection_id=ConnectionId(4)
forwarding remote control connection closed transport event connection_id=ConnectionId(5)
forwarding remote control connection closed transport event connection_id=ConnectionId(6)

Earlier in troubleshooting, the host Remote WebSocket also logged:

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

Important diagnostic result

The original Remote enrollment and installation identity were fully rotated to rule out stale local state.

After resetting:

1. A new installation ID was generated.
2. The old remote_control_enrollments row was removed.
3. ChatGPT Desktop created a new server_id and environment_id.
4. The new enrollment was persisted successfully in state_5.sqlite.
5. The host Remote WebSocket reached Connected.
6. Android re-pairing succeeded.
7. Android still reports Transport unavailable and the client-side Remote connections are immediately closed.

This appears to place the failure after host registration/WebSocket setup, at the mobile-client attach/session transport stage.

Local troubleshooting already performed

• Restarted ChatGPT/Codex Desktop
• Restarted Windows
• Signed out/in
• Removed and recreated Remote pairing
• Killed all ChatGPT/Codex processes and recreated local Remote queue/global state
• Rotated the durable Codex installation_id
• Removed the persisted remote_control_enrollments entry
• Verified a brand-new Remote enrollment was subsequently created
• Verified new server_id and environment_id values were generated
• Verified host Remote WebSocket reaches Connected
• Cleared all ChatGPT Android app data
• Re-authenticated Android app
• Re-paired Android device successfully
• Tested Windows host on normal Wi-Fi and on a phone hotspot
• Result is identical across networks
• Verified ordinary ChatGPT/Codex HTTPS authentication/API requests return 200 OK

Expected behavior

After successful pairing and after the Windows Remote host reaches Connected, the Android Remote client should attach to the host and display/control supported Codex chats.

Actual behavior

Pairing succeeds, the host is enrolled and connected, but Android cannot attach. The phone reports Transport unavailable, no chats are accessible, and each client connection is immediately closed on the host.

Suspected failure boundary

Observed sequence:

1. Authentication: works
2. Host Remote enrollment: works
3. Host WebSocket connection: works (Connected)
4. Android pairing: works
5. Android client attach: fails immediately
6. Host logs repeated remote control connection closed transport event

This looks distinct from failures where /wham/tasks/list returns 503 or where the host itself cannot establish the Remote WebSocket.

Privacy

Account IDs, installation IDs, server/environment IDs, tokens, cookies, project content, and conversation content have been omitted/redacted. Additional sanitized log excerpts can be provided if needed.

No file, test, or entry point is named. Start by tracing the Android attach/session transport after pairing and compare it with the host's repeated connection-closure logs and the Transport unavailable report. Done means a paired Android client attaches successfully, displays supported chats, and the host no longer immediately closes client connections.