Android Codex Remote disconnects before thread/resume responses reach client on Windows host
Open 💬 4 comments Opened Aug 21, 2026 by SpammkingTCG
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
Codex Remote on Android 16 cannot reliably maintain a session with my Windows ChatGPT/Codex host.
Feedback ID:
01a01fa0-40fd-7532-a1a5-7e12d30a87e8
Environment:
- Windows package: OpenAI.Codex_26.818.3698.0
- App-server build: 26.818.31338
- Android 16
- Samsung SM-S938B
- Android client: codex_chatgpt_android_remote
Symptoms:
- QR pairing succeeds.
- Android can discover the Windows host, projects and recent threads.
- Opening Codex threads often remains indefinitely on grey loading placeholders.
- Remote cycles through Connecting, Looking for ChatGPT desktop, Reconnecting, and Failed to connect to ChatGPT desktop.
- Reproduces across multiple threads and both Wi-Fi and 5G.
Local diagnostics:
- Android reaches the host and sends thread/resume requests.
- All 35 local transcript files exist.
- Thread-state and log databases pass integrity checks.
- 46 Android Remote client connections closed within one hour.
- 27 host responses were dropped after the corresponding client connection had already disconnected.
- Host logged: "Dropping message for disconnected connection".
- Main Remote WebSocket also reset once without a closing handshake.
- No relevant Windows crashes, proxy, authentication errors, or missing-thread errors.
Troubleshooting already performed:
- Latest Windows and Android apps
- Phone reboot
- Force stop / cache clear
- Android sign-out/sign-in
- Wi-Fi and 5G testing
- Fresh revoke + QR pairing
- Windows desktop restart
- Full Windows ChatGPT uninstall/reinstall
- Multiple Codex threads tested
Likely failure sequence:
- Android opens a Remote connection and sends thread/resume.
- That connection disconnects or is replaced.
- Windows completes the request against the old connection ID.
- The host drops the response because the connection no longer exists.
- Android remains on loading placeholders and starts reconnecting.
Failure window:
21 August 2026, approximately 12:46–12:51 UTC, continuing afterwards.
Please investigate Android Remote connection churn and stale connection-ID response routing/replay after reconnect, and correlate against the Feedback ID above.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
The duplicate detector surfaced #39913 and #39860, both of which appear closely related.
#39913 is particularly similar: successful Windows/Android pairing followed by Remote client disconnects and task-loading failures.
#39860 also demonstrates a Remote failure associated with larger thread/list payloads.
In my reproduction, local host logs additionally show Android sending thread/resume, followed by the logical Remote connection closing before the host response is delivered. The host then logs Dropping message for disconnected connection.
During the observed hour there were 46 Android Remote client closures and 27 dropped host responses.
My Feedback ID is:
01a01fa0-40fd-7532-a1a5-7e12d30a87e8
I’m leaving this issue open for now because the diagnostics may help correlate whether this is the same outbound-queue/payload boundary or a related stale connection-ID routing/replay problem.
My symptoms are very similar, but the Android client initially shows only the latest partial messages. Loading older messages fails repeatedly, then the conversation title changes to “Remote” and the composer/input field disappears. Retrying does not recover it. New responses may still appear when a message can be sent. Windows loads the same thread history normally. This reproduced on two Android devices, including cellular data, after app data reset, reinstall, restart, re-login, and Remote re-pairing. Android 1.2026.230 / Windows Desktop 26.818.31338. This looks like the same thread/resume response loss or Remote client hydration failure.
Same symptoms. Please help