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

Open 💬 3 comments Opened Aug 21, 2026 by youngbumkim80
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 7 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #39860

Powered by Codex Action

youngbumkim80 · 7 days ago

중복을 뭘 의미 하는지 모르겠지만 로컬1대 휴대폰1대 이렇게만 연결되어 있습니다

2026년 8월 21일 (금) 오후 2:30, github-actions[bot] @.***>님이
작성:

github-actions[bot] left a comment (openai/codex#39863) <https://github.com/openai/codex/issues/39863#issuecomment-5365594314> Potential duplicates detected. Please review them and close your issue if it is a duplicate. - #39860 <https://github.com/openai/codex/issues/39860> Powered by Codex Action <https://github.com/openai/codex-action> — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/39863?email_source=notifications&email_token=BU4M5BVFOMYXMETWDR3HJBL5K7M6PA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZWGU2TSNBTGE2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5365594314>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BU4M5BSGYG5UPJPYKOXV5X35K7M6PAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TKMRRGA3TOOBUHEYKC5QC> . You are receiving this because you authored the thread.Message ID: @.***>
youngbumkim80 · 7 days ago

Additional reproducible symptom — Android app restart only restores Remote briefly

The failure is continuing and is now reproducible in a more specific way:

  1. Remote connection from the Android ChatGPT app to the Windows host disconnects.
  2. Reconnecting normally is unreliable or fails.
  3. Fully close the ChatGPT app on the phone (remove/terminate the app), then relaunch it.
  4. Remote connects again for a short period.
  5. After a brief interval, the Remote connection drops again.
  6. Repeating the full app close/relaunch again produces the same temporary recovery followed by another disconnect.

This temporary recovery after recreating the Android client process is important because the local Windows Codex task/host can remain available while only the Remote control path fails. That pattern suggests a possible client transport/session-state/reconnect lifecycle problem rather than the local coding task itself stopping.

Current client context:

  • ChatGPT Android app: 1.2026.223
  • Android: 16
  • Host: Windows
  • Plan: Pro
  • Topology: one local Windows host + one Android phone; this is not a multi-host/multi-controller workflow.

Regarding the bot-suggested potential duplicate #39860

#39860 may be related because it also concerns Windows/Android Remote reconnect failures, but there is not enough evidence yet to close this report as a duplicate. #39860 has a specific measured trigger: an oversized initial thread/list payload (~259 KB) and unbounded previews, with connection recovery after reducing that payload. In this report, that payload-size trigger has not been measured or established. The strongest observed trigger here is different: fully restarting the Android app temporarily restores Remote, then the connection drops again shortly afterward while the local host remains usable.

Please keep this issue open unless maintainers confirm the same root cause. If useful, please advise which sanitized Remote/app-server logs or timestamps would best distinguish:

  • oversized thread/list / envelope failure,
  • WebSocket or relay disconnect,
  • Android client session-state corruption/staleness,
  • host heartbeat/app-server reattachment failure,
  • auth/session expiry or reconnect-state failure.

The current behavior makes Remote effectively unusable for sustained development because the user must repeatedly kill and relaunch the phone app just to regain a short-lived connection.