Windows host pairs with Android Remote, but conversations fail to load; `/wham/tasks/list` returns 503

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

• #39698

Powered by Codex Action

Independent same-day reproduction matching this issue's Windows build and Android setup:

• Windows x64 desktop package: OpenAI.Codex 26.818.2872.0
• Bundled app-server: 0.148.0-alpha.21
• Remote client: ChatGPT Android beta
• Desktop log window: approximately 2026-08-21T01:37Z–02:03Z

Host-side evidence after a clean Desktop restart:

• authenticated account lookup succeeds;
• remoteControl/status/read succeeds;
• remoteControl/enable succeeds twice with no error;
• the local desktop host manager reaches connected;
• subsequent Remote connection refreshes remain at previousConnectionCount=0, nextConnectionCount=0, with no local creation/enable/status error;
• Windows Store update check reports NoUpdates.

User-visible Android behavior:

• Remote stops connecting to the Windows host;
• force-stopping ChatGPT and clearing its cache can temporarily make the mobile app work, but the failure returns;
• revoking/re-pairing the phone and restarting the Desktop app do not provide durable recovery.

This suggests the host is enabled and locally healthy while the Android/pairing/list-hydration state fails to establish or persist. It is consistent with a mobile/session/backend Remote regression rather than a missing local host process.

No account IDs, device IDs, pairing material, private paths, raw logs, or conversation contents are included.

Additional user-visible symptom from the same affected environment:

• Opening any task/thread from ChatGPT Android Remote now renders only the newest chat/exchange.
• Earlier messages and conversation history never hydrate, although the full thread remains intact and readable on the Windows host.
• Opening a thread takes an unusually long time.
• During or after that wait, Remote repeatedly disconnects/reconnects.
• This affects multiple threads, not only one unusually large or old thread.
• Force-stopping ChatGPT Android and clearing its cache can temporarily revive the mobile client, but the missing-history/slow-load/disconnect behavior returns.

This narrows the impact beyond host discovery or pairing: the Remote client can reach/select a thread but fails to page/backfill its prior turns and cannot keep the transport stable long enough to recover. It appears adjacent to #37598 (Android renders an incomplete session) and #31973 (repeated/permanent reconnect failure).

No thread IDs, titles, message content, account/device identifiers, pairing data, or private paths are included.

This is a strong fit for an issue that started today for me too, right around the time of the OpenAI outage.

Last known good ~16:30 ET Aug 20; confirmed broken by ~17:00. Initially Remote couldn't connect at all. After revoking/re-pairing, Android connects normally and lists sessions, but opening any session hangs indefinitely. Windows Codex itself works normally; restart/update/AppX are healthy.

Additional live diagnostics after updating the Windows ChatGPT app and retesting Remote:

• Android Remote attempt produces correlated activity on the Windows host.
• The short-lived codex.exe process is only a normal helper/bootstrap (~390 ms) and is not the Remote daemon.
• The actual app-server remains alive, and the local codex-ipc socket/pipe remains present.
• During a targeted network trace of the Remote attempt, the app-server initiated no new outbound connection at all.
• No new SYN, no dedicated relay/WebSocket connection, no remotecontrol channel creation, no /wham/tasks/list, and no HTTP error were observed.
• A pre-existing TLS connection owned by the ChatGPT network service closed during the window, but there was no new Remote handshake attempt from app-server.

Current suspected failure point:

mobile request reaches/activates desktop -> local app-server/IPC healthy -> Remote handshake is never initiated -> no relay/channel -> no task retrieval

This makes the earlier /wham/tasks/list 503 less likely to be the immediate cause of the current failure. The current symptom appears to fail before task retrieval, during or before Remote channel orchestration/handshake.

No local crash, antivirus block, proxy/VPN, DNS/TLS issue, or socket/pipe failure was observed.

Independent reproduction on Windows + Android after the 2026-08-20 update.

Environment:

• Windows Codex/ChatGPT package: OpenAI.Codex 26.818.2441.0
• Bundled app-server launch observed as: codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled
• Bundled command runner observed: codex-command-runner-0.148.0-alpha.21
• Remote client: ChatGPT Android

User-visible behavior:

• Normal ChatGPT chats on Android work normally.
• Codex Remote worked before today's Windows update.
• After the update, existing Remote threads hang.
• A brand-new Remote thread worked briefly, then Remote failed again after only a few exchanges.
• Android Connections UI reports Transport unavailable for the Windows host.
• Codex task-completion push notifications still arrive on Android even while the live Remote connection is unavailable.
• Reinstalling the Android app, clearing cache, removing/re-pairing the connection, restarting the Windows app, and toggling Remote off/on did not provide durable recovery.

Process diagnostics:

• codex.exe app-server is present and running.
• No runaway powershell.exe ... codex.ps1 app-server proxy processes were found (Count: 0).
• The Windows app has normal established outbound HTTPS connections.

Clean-restart socket test:

1. Fully quit ChatGPT/Codex and verify Get-Process ChatGPT,codex returns nothing.
2. Reopen Desktop.
3. Before the Android Remote attempt, app-server socket states were:

Bound           4
Established     4

1. Android could not connect to the desktop host.
2. Immediately after the attempted Remote connection, app-server socket states were:

Bound           2
Established     2

No new Remote connection appeared during the attempt; instead, two existing connections disappeared. There were no CloseWait sockets in this clean-restart reproduction.

This appears consistent with the later diagnostics already posted here: the desktop app-server remains alive/local state is healthy, but a Remote handshake/relay connection is not initiated or persisted when Android attempts to connect.

Privacy note: local username, LAN IPs, device IDs, account identifiers, thread contents, and pairing material are intentionally omitted.

Independent Android + macOS/Ubuntu reproduction with host-side relay traces (2026-08-21 UTC).

Environment

• Android client: ChatGPT 1.2026.223 (20)
• macOS host: ChatGPT/Codex Desktop 26.818.31338 (build 6892), bundled app-server 0.149.0-alpha.4 — fails
• Ubuntu SSH host A: app-server 0.146.0 — fails
• Ubuntu SSH host B: app-server 0.144.0 — consistently connects
• All are on the same account/workspace.

The successful and failing Ubuntu hosts are reached through the same Mac desktop app, so the result crosses host OS and phone network boundaries.

Attempts already ruled out

• Force-stop/reopen Android app
• Sign out/in on Android
• Update and restart desktop app
• Remove/re-pair the Mac
• Wi-Fi with no VPN
• 5G mobile data with no VPN
• Fresh local host enrollment (details below)

Fresh enrollment test

With the desktop app closed, I backed up its state DB and removed only the single local remote_control_enrollments row. After reopening and re-enabling Remote, the log explicitly reported:

1. no persisted enrollment found;
2. a newly persisted local enrollment at 03:46:30Z;
3. the app-server WebSocket becoming Connected to wss://chatgpt.com/backend-api/wham/remote/control/server at 03:46:31Z.

The service returned the same stable server/environment identity as before the local reset. The Android connection still failed immediately.

Correlated transport trace

At 03:46:53Z–03:47:17Z, one Android retry sequence generated monotonically increasing integer request IDs 25–32 across two different hosts:

• macOS received IDs 25, 26, 27, and 30;
• Ubuntu app-server 0.146.0 received IDs 28, 29, 31, and 32.

On both failing hosts, each remote connection delivered only initialize and then closed in roughly 0–250 ms. In some attempts, the close was forwarded before initialize finished processing, producing dropping message for disconnected connection. No thread/list request followed.

During the same test, the Ubuntu app-server 0.144.0 host remained green/usable in Android Remote.

User-visible errors include “Failed to connect to ChatGPT desktop” and “Transport unavailable.” The desktop hosts remain healthy and their local task lists are intact.

This evidence suggests a mobile/relay handshake or protocol-compatibility regression affecting newer host runtimes, rather than direct host networking, host OS, stale local enrollment, or a missing desktop process. It also matches the newer report above that the failure can occur before task retrieval.

No account IDs, device/server/environment IDs, pairing material, private paths, raw logs, or conversation contents are included.

Independent same-day Windows + Android reproduction, with host-side desktop logs that distinguish the Remote failure from the underlying SSH connection.

Environment

• Windows Codex Desktop 26.814.41407 when the incident began
• Updated to Codex Desktop 26.818.31338 during troubleshooting
• ChatGPT Android Remote client
• One direct Windows environment and one SSH-backed Linux environment presented through the same Windows desktop app
• Both Remote targets became unavailable on Android, while the Windows desktop app remained able to open and use the SSH-backed environment

Correlated timeline (UTC)

The original desktop session recorded a brief Windows network interruption:

2026-08-20T21:31:40.610Z  network_restored_reconnecting
                              offlineDurationMs=6049
2026-08-20T21:31:43.924Z  reconnect started for SSH-backed environment
2026-08-20T21:31:44.381Z  SSH app-server transport connection succeeded
2026-08-20T21:31:44.425Z  SSH-backed environment connected

The SSH path therefore recovered in roughly four seconds. The Windows desktop could continue using that environment, but Android Remote did not recover access to either the direct Windows environment or the SSH-backed environment.

After updating the Windows app, the logs captured a direct Remote transport failure followed by an unexpected local app-server exit:

2026-08-21T02:57:52.370Z  remote control websocket reader was stopped
2026-08-21T02:58:30.140Z  local Codex CLI/app-server exited unexpectedly
                              classifiedAsExpected=false code=1

A later Remote client-list request also failed at the service boundary after 30 seconds:

2026-08-21T03:44:56.705Z  remoteControl/client/list failed
                              durationMs=30029
                              request=https://chatgpt.com/backend-api/wham/remote/control/environments/<redacted>/clients

Across fresh desktop sessions on 26.818.31338, the local Windows app-server exited unexpectedly six times:

2026-08-21T01:46:54.754Z  classifiedAsExpected=false code=1073807364
2026-08-21T02:58:30.140Z  classifiedAsExpected=false code=1
2026-08-21T04:02:41.588Z  classifiedAsExpected=false code=1
2026-08-21T04:11:28.116Z  classifiedAsExpected=false code=1
2026-08-21T04:37:28.715Z  classifiedAsExpected=false code=1
2026-08-21T04:42:36.977Z  classifiedAsExpected=false code=1

The sessions also repeatedly received 401 responses containing Must use workspace account for this operation, primarily while fetching account settings. I cannot establish from these logs whether those responses caused the Remote failure, but they may be useful when correlating account/workspace state.

Assessment

This appears to be a failure in the shared desktop Remote/relay/account-session path, rather than two independent host failures:

1. A short host network interruption occurred.
2. The SSH-backed environment reconnected immediately and remained usable from Windows.
3. Android lost both environments that depended on the same Windows Remote presentation.
4. Subsequent sessions showed a stopped Remote websocket reader, a timed-out Remote clients API call, and repeated unexpected app-server exits.

This is distinct from #37142, which concerned SSH-backed environments being omitted before per-SSH Remote enablement was available. That functionality was present here; the problem is loss of established Remote availability and failure to recover.

All hostnames, LAN addresses, account/environment/client IDs, pairing material, private paths, thread contents, and raw logs are intentionally omitted. Full logs can be provided privately to maintainers if needed.

Additional A/B result from the original Windows/Android environment:

I archived essentially all inactive Codex threads and left only two active top-level threads (one primary project thread and one diagnostic thread). Android Remote still fails exactly as before.

This makes the large thread/list payload / too-many-active-threads explanation from #39860 much less likely for this host, at least as the immediate cause of the current failure.

Important details:

• No threads were deleted; only archived through the supported UI/tooling.
• No .codex files, SQLite databases, rollout JSONL files, enrollment rows, installation IDs, or Remote metadata were manually modified.
• After reducing the active thread set to two, Remote was toggled/retried and the failure persisted.
• The protected project/thread data remains intact and usable locally on Windows.

This result fits better with the other reproductions here where the failure occurs during/before the Remote handshake or transport setup, before task retrieval/list hydration.

Independent reproduction on Windows + Android, with a newer Windows package and a reproducible cache-related symptom.

Environment

• Windows host, native Windows project path (not WSL)
• ChatGPT/Codex desktop package: OpenAI.Codex 26.818.3698.0
• Bundled app-server observed as a single process:

codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled

• Client: ChatGPT Android app

Symptoms

• Android Remote intermittently stays on Connecting... even though the Windows host (user-PC) and an existing project are visible.
• When it does connect, opening an existing Codex thread shows only loading skeletons; prior conversation history never hydrates.
• The connection then becomes unavailable again shortly afterward.
• Clearing the ChatGPT Android app cache temporarily restores the Remote connection, but the failure returns quickly.

Isolation already performed

• Restarted the Android app multiple times: no durable recovery.
• Restarted the Windows ChatGPT/Codex app: no durable recovery.
• Switched the Windows host from the normal home connection to mobile tethering: behavior unchanged, so the home router/ISP does not appear to be the cause.
• PC browser ChatGPT loads and syncs conversations normally; general OpenAI connectivity/account sync is working.
• Windows desktop ChatGPT also shows current Chat conversations after restart.
• Windows Codex itself is healthy: existing projects/threads are present and usable locally.
• Created a fresh empty native-Windows project (C:\codex-remote-test) and a new thread on the desktop. It appears normally on Windows, but the new project/thread does not appear in Android Remote.
• Confirmed only one Codex app-server process; no obvious duplicate proxy/process accumulation.

Expected

Android Remote should maintain a stable connection to the paired Windows host, list newly created desktop projects/threads, and hydrate full thread history.

Actual

Host discovery can work, but Remote connection is unstable; clearing Android app cache only fixes it temporarily. When connected, project/thread synchronization and history hydration remain incomplete.

This looks very similar to the failure described in this issue, with the additional reproducible observation that clearing the Android ChatGPT cache temporarily restores connectivity before the Remote state becomes broken again.

very great........

Same issue here.

• Windows Codex host + ChatGPT Android
• Phone: Samsung Galaxy Z Fold7 (SM-F966N)
• Remote pairing succeeds
• The phone is listed under “Devices that can control this PC” with a recent connection timestamp
• But the Windows host never appears in the Android Remote view, so no Codex tasks/conversations can be accessed
• This worked normally until the morning of Aug 21, 2026
• Re-pairing, restarting both apps/Windows, toggling Remote Control, and clearing the Android app cache did not help

Screenshot attached: Windows shows the Android phone as recently connected.

<img width="824" height="192" alt="Image" src="https://github.com/user-attachments/assets/3790698c-53d4-4e78-a071-8a8cc822fd35" />

Same here. Short threads work, but not long threads. I also connect my android phone to Linux hosts, and it also cannot load long threads from them.

Additional intermittent-behavior detail from the original Windows/Android environment:

Remote currently alternates between working and unavailable states.

When it partially recovers:

• a small diagnostic thread can load and display its conversation normally;
• a much larger primary project thread does not hydrate correctly;
• it can sometimes still accept/send a new prompt even when prior history is not loading correctly.

Afterward, the entire Windows host can become unavailable/red in Android Remote again.

This suggests two overlapping failure modes may be present:

1. unstable Remote transport/session availability;
2. a separate history-hydration problem that disproportionately affects large/long threads.

No project names, thread IDs, conversation contents, account/device identifiers, pairing material, local paths, or private data are included.

I am having the same issue, with my andriod app and windows codex, none of the ssh connection projects are shown in the andriod app although they are shown in the windows app. Feedback id 01a041c2-dad3-7000-a4dd-c3826b92b44f