[Bug] Android Remote stopped connecting to Windows host before desktop update; pairing still succeeds

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

What version of the Codex / ChatGPT Desktop app are you using?

Current version: 26.818.32112 (released Aug 21, 2026).

Important: the Remote failure started before I updated to this build. The desktop was still on the previous build when the problem began. Updating to 26.818.32112 did not fix it.

Subscription

ChatGPT Plus.

Platform

Host: Windows desktop running the new ChatGPT Desktop / Codex integration.

Remote client: ChatGPT for Android 16, Infinix X6876, latest version available from Google Play.

What issue are you seeing?

Codex Remote had been working normally, including for an active project/workflow. Around 2026-08-20 at approximately 23:50 EEST (UTC+3), the Android Remote connection stopped working and has remained unusable since.

On Android, the Windows host is visible but shows a red/offline indicator. Attempting to connect produces:

Failed to connect to ChatGPT Desktop Make sure the ChatGPT desktop app is open, then try again.

The desktop app is open, online, signed in, and Remote connections are enabled.

Pairing itself succeeds. The Android device appears in the Windows ChatGPT Desktop Remote/Connections settings as an authorized device. Importantly, when I press Try again on Android, the desktop's Last connection timestamp for that Android device updates (for example, to 1 min). This suggests the phone reaches the desktop/backend enrollment layer, but the live Remote session still fails to establish.

Reproduction / troubleshooting already completed

  1. Confirmed Allow connections / Remote Control is enabled on Windows.
  2. Confirmed the Android phone is paired and listed on the desktop.
  3. Revoked/re-paired the phone with a fresh QR code.
  4. Fully exited and restarted ChatGPT Desktop.
  5. Toggled Remote connections off and back on.
  6. Opened Codex and the active project on the Windows host.
  7. Updated the Android ChatGPT app to the latest Google Play version.
  8. Switched the phone from Wi-Fi to cellular data; no change.
  9. Confirmed ChatGPT Classic is not relevant: it is installed but not signed in; the active host is the new ChatGPT Desktop app.
  10. Updated Windows ChatGPT Desktop to 26.818.32112; no change.

The failure therefore predates the current desktop build and survived the update.

Expected behavior

A paired Android device should connect to an awake, online Windows ChatGPT/Codex host and allow access to the active Codex project/thread.

Actual behavior

Pairing and device registration succeed, and the desktop records fresh connection attempts, but Android cannot establish a usable Remote session.

Impact

This has blocked my active Codex project/workflow for almost a full day. I rely on Remote to continue supervising and interacting with the project while away from the Windows PC. There is currently no useful recovery action exposed to the user beyond re-pairing/restarting, and none of those steps resolved the problem.

This is especially disruptive because the desktop project itself remains intact and usable locally, but the Remote path is unavailable with no actionable diagnostic or recovery control.

Related reports

This appears closely related to:

  • #39947 — Android Remote became unusable / Windows host appears disconnected
  • #39856 — QR pairing succeeds but Android cannot establish Remote session
  • #39954 — Windows + Android Remote reconnect loop / session lifecycle desynchronization
  • #39974 — Remote Control unstable while Windows Desktop works normally

The key additional data point in this report is that the failure began around 2026-08-20 23:50 EEST, before updating the Windows desktop client, and that the desktop still updates the Android device's Last connection timestamp during failed connection attempts.

Screenshots of the Android error, Windows Remote settings, and desktop version are available if maintainers need them.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 6 days ago

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

  • #39907
  • #39947
  • #39856
  • #39865
  • #39954

Powered by Codex Action

pueblokc · 6 days ago

having the same issue its been ongoing since yesterday nothing helps

psikosen · 6 days ago

I'm having the same issue from my Linux and mac pc as well. It either continues to say connecting or it eventually fails and says try again.

LoganSUS · 6 days ago

Update from the original reporter:

The issue recovered spontaneously this morning without any local configuration change.

During the outage I followed the troubleshooting guidance from OpenAI Support, including:

  • revoking and re-pairing Android with a fresh QR code,
  • fully signing out of ChatGPT Desktop and signing back in with my personal Plus account,
  • re-enabling Remote / Allow connections,
  • fully restarting the desktop app,
  • toggling Remote off/on,
  • updating both Android and Windows apps,
  • switching the Android client from Wi-Fi to cellular data,
  • confirming the Windows host was awake and the desktop app was open.

None of those steps restored Remote at the time.

The important point is that Remote later started working again without me changing firewall, VPN, proxy, DNS, router, pairing, Windows settings, or the Codex project state. OpenAI Support has also noted on my support case that pairing/registration continued to work during the outage because the desktop Last connection timestamp kept updating during failed Android attempts.

This makes a persistent host-specific Windows/network configuration problem much less likely.

Also, other users are now reporting the same behavior on additional platforms, including Linux and macOS, while some users are still affected even after my connection recovered. That pattern looks more consistent with a transient or inconsistent Remote backend / relay / session-lifecycle failure than with a single local setup problem.

Please do not interpret this report as resolved by user troubleshooting. It recovered on its own after roughly a day of failure.

saffih · 6 days ago

me too. same but i reverted ... thank you

tw0709 · 5 days ago

I have the same issue, but it doesn't recover itself.
I think this is still an bug for some people