Android remote control session list stays stale while Codex Desktop has newer sessions
Description
The ChatGPT Android remote-control session list for Codex Desktop appears stale. Recent Codex Desktop sessions exist locally and are visible from desktop/iOS, but the Android remote-control session list only shows old sessions, around 4 days behind. Android can still resume/control older sessions, so the remote-control channel is not completely broken.
I am filing this on behalf of a user who is currently controlling Codex from the Android app.
Expected behavior
The Android remote-control session list should show the same recent Codex Desktop sessions as the desktop app / iOS remote-control view.
Actual behavior
As of 2026-05-25 23:26 Asia/Shanghai, the local Codex Desktop thread DB contains fresh sessions, including:
019e5fb5-...updated2026-05-25 23:26, title starts with最新的session是哪一个?为什么我这里看不到?019e5ddc-...updated2026-05-25 23:20, title starts with我在手机,安卓手机上远程连接你...
However, the Android app's remote-control session list only shows sessions from around 4 days ago. Reinstalling the Android app, restarting the phone, switching accounts away/back, and reauthorizing remote control did not refresh the list.
The user also reports that deleting the device/list entry from Android is not a viable workaround because it removes the device across all devices.
Diagnostics from the desktop machine
Environment:
- Codex Desktop app version observed in logs:
0.133.0-alpha.1 - Codex CLI:
codex-cli 0.130.0 - macOS:
26.5build25F71 - Android remote client name/version observed in logs:
codex_chatgpt_android_remote, versiondev - iOS remote client version observed separately in logs:
1.2026.132
Local thread storage is up to date:
~/.codex/state_5.sqlitethreadstable lists multiple sessions updated on2026-05-25, including the two above.~/.codex/sessions/2026/05/25/...019e5fb5...jsonlexists for the latest session.
Remote-control enrollment/state looks suspicious:
remote_control_enrollmentshas a current local environment ID ending in...dc91, server nameappledeMacBook-Pro-3.local, last updated2026-05-19 12:57:32local time.~/.codex/.codex-global-state.jsonhaselectron-local-remote-control-environment-idending in...dc91, butselected-remote-host-id,added-remote-control-env-ids, andremote-connection-auto-connect-by-host-idpoint to a different environment ID ending in...3115.
Logs suggest the Android client is not refreshing the session list from the current desktop server:
- Recent Android remote logs show
thread/resumecalls for older thread IDs. - No recent Android-originated
thread/listrequest was found. - The only recent
thread/listrequests observed were fromCodex Desktop, not fromcodex_chatgpt_android_remote. - Remote/plugin sync logs complete successfully, so the remote-control transport itself appears to be working.
Steps already tried by the user
- Android app uninstall/reinstall
- Phone reboot
- Switch account away, then switch back
- Reauthorize remote control
- Resume older sessions from Android still works
Suspected area
This looks like either:
- Android remote-control session list/backfill is stuck on an old cursor or old remote environment, or
- Android is selecting an old remote host/environment even though the current desktop enrollment points to a newer environment, or
- Android remote-control list refresh is not issuing
thread/listagainst the active desktop app-server.
I did not include account email, account ID, or complete internal IDs in this report.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I'm having the same issue.
Codex CLI: codex-cli 0.130.0
Codex desktop: 26.519.81530 build 3178
ChatGPT for Android: 1.2026.125 build 19
A few interesting things I noticed:
Additional current reproduction with host-side and Android diagnostics (2026-08-21/22, Europe/Warsaw):
Environment
1.2026.223(build2622320)26.818.31338(build6892)0.149.0-alpha.4Observed behavior
codex_chatgpt_android_remote.initializeand closes the remote connection about 0.1–0.2 seconds later. It does not sendthread/list.initialize+thread/listand the channel remained open briefly, but Android still kept spinning. Subsequent retries reverted toinitializefollowed immediately by disconnect.Already tried, without effect
This looks related to the original report's missing Android
thread/list, but the current failure mode is stronger: the Android client usually disconnects immediately afterinitializeand leaves the UI spinning. It does not appear to be caused by local task contents, task count, Android app data, or basic host connectivity.No account identifiers, hostnames, complete environment IDs, task IDs, or transcript contents are included here.