Android remote control session list stays stale while Codex Desktop has newer sessions

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

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-... updated 2026-05-25 23:26, title starts with 最新的session是哪一个?为什么我这里看不到?
  • 019e5ddc-... updated 2026-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.5 build 25F71
  • Android remote client name/version observed in logs: codex_chatgpt_android_remote, version dev
  • iOS remote client version observed separately in logs: 1.2026.132

Local thread storage is up to date:

  • ~/.codex/state_5.sqlite threads table lists multiple sessions updated on 2026-05-25, including the two above.
  • ~/.codex/sessions/2026/05/25/...019e5fb5...jsonl exists for the latest session.

Remote-control enrollment/state looks suspicious:

  • remote_control_enrollments has a current local environment ID ending in ...dc91, server name appledeMacBook-Pro-3.local, last updated 2026-05-19 12:57:32 local time.
  • ~/.codex/.codex-global-state.json has electron-local-remote-control-environment-id ending in ...dc91, but selected-remote-host-id, added-remote-control-env-ids, and remote-connection-auto-connect-by-host-id point 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/resume calls for older thread IDs.
  • No recent Android-originated thread/list request was found.
  • The only recent thread/list requests observed were from Codex Desktop, not from codex_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:

  1. Android remote-control session list/backfill is stuck on an old cursor or old remote environment, or
  2. Android is selecting an old remote host/environment even though the current desktop enrollment points to a newer environment, or
  3. Android remote-control list refresh is not issuing thread/list against the active desktop app-server.

I did not include account email, account ID, or complete internal IDs in this report.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #24447
  • #23152
  • #23070
  • #23098

Powered by Codex Action

petegivens · 3 months ago

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:

  • When I add a new chat in the desktop app while the mobile app is connected, I briefly saw the new thread flash in the mobile app, then disappear.
  • When I start a new chat in the mobile app, it syncs to the desktop app, but then disappears from the mobile app when I pull down to refresh.
  • The last visible chats I see in the mobile app are marked as 3d old, but in the desktop app they show as 4d old.
czajah · 6 days ago

Additional current reproduction with host-side and Android diagnostics (2026-08-21/22, Europe/Warsaw):

Environment

  • ChatGPT Android: 1.2026.223 (build 2622320)
  • Device: Samsung SM-S918B
  • macOS ChatGPT/Codex desktop: 26.818.31338 (build 6892)
  • Bundled Codex CLI/app-server: 0.149.0-alpha.4

Observed behavior

  • Remote host is shown as connected, but the Android session/task surface spins indefinitely and never becomes usable.
  • The same setup worked normally roughly two days earlier. The failure appears to have started after a task was initiated from Android.
  • Desktop logs show repeated connections from codex_chatgpt_android_remote.
  • On failing attempts, Android sends initialize and closes the remote connection about 0.1–0.2 seconds later. It does not send thread/list.
  • After one fresh desktop restart, a single attempt reached initialize + thread/list and the channel remained open briefly, but Android still kept spinning. Subsequent retries reverted to initialize followed immediately by disconnect.
  • Android ADB/logcat showed no ChatGPT process crash and no obvious TLS/SSL or ordinary network error.
  • Local thread storage and local app-server listing remain healthy.

Already tried, without effect

  • Clear Android app data/cache
  • Uninstall/reinstall ChatGPT
  • Phone reboot
  • Desktop restart
  • Reauthorize/re-pair Remote Control
  • Reset the desktop Remote Control enrollment/identity and register a fresh environment
  • Temporarily isolate/archive recent and imported task batches to test whether a malformed/large task payload caused the failure (all restored afterward)

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 after initialize and 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.