Windows + Android Remote Control enters reconnect loop after successful initialize/thread-list

[cesariveiro-lang]

Summary
Codex Remote Control on Windows is currently unusable from Android.
The issue initially appeared as:
409 Conflict
{"detail":"Remote app server already online"}
That stale-server condition has since been cleared. The Windows app-server now connects successfully to the Remote Control websocket and reports Connected, but Android still cannot establish a usable Remote session.
Versions

• Codex Desktop: 26.818.31338
• Bundled app-server: 0.149.0-alpha.4
• ChatGPT Android: 1.2026.223 (20)
• Android 16
• Windows 11 desktop host
  Current behavior
  On clean startup, Remote Control looks healthy:
  remoteControl/status/read ... errorCode=null
  remote control websocket status changed ... next_status=Connected
  connected to app-server remote control websocket
  remoteControl/enable ... errorCode=null
  The original 409 is no longer present.
  During an Android connection attempt at:
  2026-08-21 14:45:07 UTC
  the Windows app-server receives:
  initialize connection_id=ConnectionId(2) request_id=Integer(10)
  thread/list connection_id=ConnectionId(2) request_id=Integer(11)
  initialize was received at approximately 14:45:07.080Z and thread/list at 14:45:07.673Z, about 593 ms later.
  No local error or connection closed event is logged for ConnectionId(2).
  After that, new remote connections are opened. ConnectionId(3) through ConnectionId(9) are created and then immediately closed:
  initialize ConnectionId(3)
  forwarding remote control connection closed ... ConnectionId(3)
  and in some cases:
  forwarding remote control connection closed ... ConnectionId(4)
  initialize ConnectionId(4)
  dropping message for disconnected connection: ConnectionId(4)
  dropping message for disconnected connection: ConnectionId(4)
  The same pattern repeats for later connection IDs.
  On Android, the PC is discovered and shown as connecting/reconnecting, but the session never becomes usable.
  Historical comparison
  The same logs_2.sqlite contains older healthy Remote sessions where the flow continues normally:
  initialize ConnectionId(3)
  thread/list ConnectionId(3)
  ...
  connection closed ConnectionId(3)
  Other historical sessions also reach:
  initialize ConnectionId(4)
  thread/list ConnectionId(4)
  This shows that the Android client and the app-server are capable of completing the handshake and progressing beyond initialize.
  Troubleshooting already performed
• Full Desktop restart
• Reinstalled Codex Desktop from Microsoft Store
• Revoked and re-paired Android
• Cleared Android cache and full app storage
• Signed in again and re-paired
• Backed up Codex state
• Cleared remote_control_enrollments
• Removed persisted Remote Control environment/installation keys from global state
• Rotated the main Codex installation_id
• Confirmed the new installation identity differs from the previous one
• Fixed an accidental UTF-8 BOM in .codex-global-state.json and its backup
• Confirmed clean startup loads global state normally
• Confirmed Remote websocket is currently Connected
• Confirmed the original 409 is gone
  The problem still reproduces with the fresh installation identity.
  Expected behavior
  After Android sends:
  initialize
  thread/list
  the Remote session should remain usable and display the host's conversations.
  Actual behavior
  One connection reaches:
  initialize -> thread/list
  but never becomes usable on Android.
  After that, new remote connections are repeatedly opened and immediately closed during initialize.
  Suspected area
  This looks like a Remote Control session/relay lifecycle desynchronization rather than a basic pairing, firewall, local enrollment, or host websocket problem.
  It appears possible that one side still considers the first Remote connection alive while another part of the Remote Control path starts opening replacement connections.
  Related issue
• remote-control 409 stale enrollment needs supported takeover or repair path #28862 — stale Remote enrollment / 409 Remote app server already online
  I can provide sanitized excerpts from logs_2.sqlite with exact timestamps if needed. Account IDs, installation IDs, server IDs and environment IDs are intentionally omitted.

[github-actions]

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

• Android Remote fails during thread/list when unbounded previews make the first response ~259 KB #39860
• Android Codex Remote disconnects before thread/resume responses reach client on Windows host #39931
• [Remote][Windows/Android] Pairing succeeds and host WebSocket is Connected, but Android attach immediately closes with Transport unavailable #39915

Powered by Codex Action

[cesariveiro-lang]

Update: I found a working workaround, and this now looks much closer to #39860 than I initially thought.

What I tested:

• Before changing anything, the active vscode thread set had 27 threads with:
  • 464,660 total first_user_message characters
  • largest message: 50,831 characters
  • 23/27 over 512 chars
  • 18/27 over 8,000 chars
• preview matched first_user_message exactly in the state DB, so the previews were effectively unbounded.
• I first marked older threads archived directly in state_5.sqlite, reducing active vscode threads from 27 to 2 and active first-message content to only 20,929 characters.
• Despite that DB change, Codex Desktop still showed the old threads in Recents, and Remote still failed. This suggests the supported UI/archive path and the raw DB flag are not equivalent for the Remote list/reconciliation path.

Then I archived the old threads from the Codex Desktop UI itself, revoked the Remote connection, and created it again.

Result: Android Remote connected successfully and the recent/project list loaded normally.

So the current A/B result is:

• Large/unbounded thread set -> Android Remote fails/reconnects
• Raw SQLite archived=1 only -> still fails
• Archive old threads through the Codex UI + recreate Remote connection -> Remote connects successfully

This strongly suggests my persistent failure was triggered by the effective Remote thread/list / reconciliation payload rather than basic pairing, firewall, or host WebSocket setup. The original 409 Remote app server already online may have been a separate stale-session issue at the beginning.

This appears closely related to #39860. The detail that direct DB archiving did not change the effective behavior, while archiving through the supported UI did, may be useful when tracing how Desktop builds/reconciles the Remote thread list.

I am leaving this issue open for now because the failure mode included the reconnect/connection-ID churn documented above, but the supported-archive workaround is currently working.

[cesariveiro-lang]

Follow-up: the previous workaround was only temporary. Remote has now regressed again, and the new logs narrow the failure further.

After archiving old threads through the supported Codex Desktop UI and recreating the Remote pairing, Android connected successfully for a while. Small threads opened normally, while one very large legacy thread did not hydrate or took an extremely long time. That large thread has ~38.5k rollout items, but total rollout size alone is not explanatory: another legacy thread with a larger total rollout (~201 MB vs ~114 MB) opens successfully on Android.

More importantly, once Remote failed again, the transport pattern changed to an earlier-stage failure:

• repeated Remote connections are created;
• each reaches initialize;
• the Remote connection closes almost immediately;
• many retries then repeat the same pattern;
• some responses are later dropped because the connection is already gone.

Examples from the affected window:

initialize connection_id=ConnectionId(35)
forwarding remote control connection closed transport event connection_id=ConnectionId(35)

initialize connection_id=ConnectionId(36)
forwarding remote control connection closed transport event connection_id=ConnectionId(36)

initialize connection_id=ConnectionId(40)
forwarding remote control connection closed transport event connection_id=ConnectionId(40)

initialize connection_id=ConnectionId(46)
forwarding remote control connection closed transport event connection_id=ConnectionId(46)

This continued through many replacement connection IDs (roughly 35-57 in the captured window). Separate log lines also showed dropping message for disconnected connection for some of those retries.

Critically, in this regressed state there is no Remote-side thread/list, thread/resume, or thread hydration after initialize. So the current failure happens before the client even gets as far as listing/opening threads.

The thread/resume / thread/turns/list activity around the same time is ConnectionId(0) and therefore local Codex Desktop stdio activity, not the Android Remote connection. Desktop can parse the large rollout successfully (38544 items, parse errors: 0).

Auth also appears healthy locally (OAuth token refresh returned 200 OK), and pairing/revocation itself succeeds, so this does not look like a basic auth or pairing failure.

Current interpretation:

1. There is a thread-hydration/performance issue for very large legacy threads when Remote is otherwise working (possibly related to Paginated thread bootstrap loads up to 500 items without a byte limit, so one large turn remains slow #38653/Android Remote cannot start turns in an idle large task: turn/start times out after 30s #38023).
2. Separately, there is a Remote session/connection-lifecycle failure where Android reaches initialize and the logical Remote connection is immediately torn down, then retried in a loop. This second failure makes Remote completely unusable and is the current blocker.

Because the UI-archive workaround only restored service temporarily, I no longer think #39860 alone fully explains this issue.

[cesariveiro-lang]

Further update / correction on timing:

The Remote disconnect did not happen immediately after submitting the prompt. The Codex turn had already been running on the Windows host for at least ~15 minutes when the later Remote failures were captured.

Observed during the already-active turn:

• Codex Desktop continued executing the task normally on Windows.
• Android Remote repeatedly lost its logical connection.
• Remote connection IDs in the captured window closed in succession (for example ConnectionId(62), (63), (64), (65)).
• For one of those closed connections the host then logged dropping message for disconnected connection twice.
• The active Codex task itself was not cancelled by the Remote disconnect and continued running on Desktop.

So the stronger interpretation is not "turn/start causes the disconnect". Instead, an already-running task can survive while the Remote interactive session dies independently.

This further separates task execution from Remote session transport/lifecycle:

turn already active on host -> Remote connection closes/reconnects -> some messages target an already-disconnected connection -> host task continues

That seems consistent with stale/replaced connection-ID routing or Remote session lifecycle instability rather than a general Codex Desktop failure.

Also potentially related: #39974 reports very similar Remote instability across Android and iOS while Windows Desktop remains functional, including brief successful connections followed by disconnects and thread-loading failures.

[cesariveiro-lang]

Additional observation that may help isolate the failing layer:

After Remote had already become unable to establish a usable interactive session, I closed Codex Desktop and reopened it later. The Android notification shade then showed:

• a persistent Remote notification saying it was connecting to the Windows host (not connected yet), while
• separate Codex notifications delivered completed task results such as RESULT: PASS and RESULT: PARTIAL.

So the system can still deliver Codex execution/status notifications while the interactive Remote session remains unavailable.

This suggests the failure is narrower than general host/account connectivity:

• Codex Desktop execution: working
• task completion/status delivery / push notifications: working
• interactive Remote session / relay connection: failing

This also matches the pattern described in #39974, where notifications/approval updates can still arrive while Remote reports the host/session as unavailable.

I cannot prove from the UI alone whether those notifications were queued and flushed on host restart or generated through a separate live path, but the important point is that notification delivery remains functional while Remote itself cannot connect.

[staszw]

macOS + Android reproduction with desktop version matrix

I can reproduce the same failure on a macOS host with ChatGPT for Android 1.2026.223 on Android 16.

Observed flow

• The host Remote WebSocket reaches and remains Connected.
• Pairing succeeds and the Android device is enrolled.
• Each Android attempt reaches the host, then the logical connection closes 0–600 ms after initialize:

initialize connection_id=ConnectionId(N)
remoteControl/status/changed targeted_connections=1
forwarding remote control connection closed transport event connection_id=ConnectionId(N)

• Some races also log dropping message for disconnected connection.
• In the final reproductions there is no Remote-side thread/list or thread/resume after initialize.
• One fresh post-reinstall attempt briefly reached thread/list, but later retries regressed to the immediate initialize/close loop.

Desktop version matrix

ChatGPT Desktop	Bundled app-server	Result
26.803.61601	0.147.0-alpha.6.5	Same initialize/close loop
26.818.22352	0.148.0	Same initialize/close loop
26.818.32112	0.149.0-alpha.4.1	Same initialize/close loop

Troubleshooting already performed

• Full desktop and Mac restarts
• Phone tested on cellular data
• Server Remote environment recreated after stale-environment detection
• Fresh QR pairing
• Mobile cache cleared and app fully reinstalled
• Pre-reinstall duplicate device grant revoked
• Newest desktop build and an older desktop build tested

During the final reproductions there was no 401/403, environment-not-found response, queue overflow, or app-server crash. The host Remote WebSocket stayed connected.

This cross-platform reproduction makes a Windows-specific desktop regression less likely and points instead to Android 1.2026.223 or server-side Remote session/protocol compatibility.

The report intentionally excludes account identifiers, installation/server/environment IDs, device model, location, local paths, tokens, and QR data.