[Remote][Windows/Android] Remote Codex connection repeatedly disconnects during long-running sessions

What issue are you seeing?

Remote Codex connections are repeatedly disconnecting during long-running coding sessions, to the point that Remote is not reliable enough for sustained project work.

This is not an isolated one-time disconnect. The Remote connection repeatedly drops while the local Codex work on the host can otherwise continue, and reconnecting is unreliable or requires repeated attempts.

The issue is especially disruptive for large, long-running development tasks where continuity of the same Codex session matters.

Environment

• ChatGPT plan: Pro
• Host platform: Windows
• Remote controller/client: ChatGPT Android app
• Workload: large local software project with long-running Codex tasks
• Local execution on the host can continue, while the Remote connection is the unstable part

Exact Codex/ChatGPT build numbers can be supplied if needed.

What steps can reproduce the bug?

1. Start or continue a Codex task on a Windows host.
2. Connect to that host through ChatGPT Remote from an Android device.
3. Continue a long-running coding session with multiple turns and tool executions.
4. Leave the task running or continue interacting remotely for an extended period.
5. Observe that the Remote connection disconnects repeatedly.
6. Attempt to reconnect and continue the same task.
7. The connection may fail again, become unstable, or require repeated reconnection attempts even though the local host/session itself is still available.

The problem has occurred repeatedly rather than as a single transient network event.

What is the expected behavior?

Remote should maintain a stable connection for long-running Codex sessions and recover transparently from brief transport interruptions.

If the network momentarily changes or a WebSocket/transport connection drops:

• the existing Codex task should remain intact;
• Remote should automatically reconnect to the same host/session;
• context and task state should not be lost;
• the user should not need repeated manual reconnection attempts;
• long-running development work should remain controllable from the Android client.

Actual behavior

• Remote disconnects repeatedly during active or long-running work.
• Reconnection is unreliable.
• The local host can still be working while Remote becomes unavailable.
• The instability interrupts development and makes Remote unsuitable for sustained Codex use.

Impact

Severity is high for users who rely on Remote for serious development workflows.

For large coding projects, repeated Remote disconnects can interrupt supervision of long-running tasks, force repeated recovery attempts, waste user time, and create uncertainty about whether a task is still running or whether state/context has been preserved.

Requested investigation

Please investigate the Remote connection lifecycle, including:

• WebSocket / long-lived transport stability;
• reconnect/backoff behavior;
• Android-to-host Remote session recovery;
• host/session identity preservation across reconnects;
• whether an existing healthy local task is incorrectly treated as unavailable after a Remote transport failure;
• whether Remote reconnect attempts can enter a stale or failed state instead of reattaching to the existing session.

It would also be very helpful to expose a user-visible diagnostic reason when Remote disconnects (transport failure, auth/session expiry, host heartbeat loss, app-server failure, etc.) instead of only presenting a generic lost connection.

Additional information

This report intentionally omits private project contents, credentials, session IDs, and filesystem details. I can provide sanitized timestamps, logs, screenshots, and exact app/Codex versions if the Codex team requests them.

No files, tests, or entry points are named. Start by reproducing a long-running Windows-host and Android-client session while tracing the Remote transport and reconnect lifecycle, then inspect how host and session identity are preserved after disconnects. Done should include reliable reattachment without lost task state, plus a diagnostic reason when recovery fails.