Android Remote Control does not load host thread history (no thread/list requests observed)

Additional observation that looks related to mobile remote conversation listing / restore, not only host-history loading:

On Android Remote Control, the mobile UI currently only shows the latest conversation created from the phone. If I create a second conversation from Android, the previous Android-created conversation disappears from the mobile list. If I leave/disconnect and connect again, none of the Android-created conversations are visible in the mobile UI.

The conversations are not expected to be deleted from the Mac host; this looks like the Android/mobile remote conversation list is not being persisted/re-listed/restored correctly.

This overlaps with the symptoms reported in:

• #22819 — mobile remote does not persist or re-list projectless conversations after reconnect
• #22800 — Android mobile loses Android-started active threads after force quit

So the issue may be broader than “Android does not request host history”: Android Remote Control also appears unable to maintain a stable list of mobile-created remote conversations across new-conversation switches and reconnects.

I am seeing what looks like the same underlying Android Remote Control / Codex remote listing problem.

Environment:

• Codex App: 26.513.31313 (2867)
• Subscription: ChatGPT Pro 5x
• Platforms: macOS host + Android ChatGPT app / remote control

Observed behavior:

• In the ChatGPT app's Codex remote flow, many existing remote projects do not show up in the project list.
• If I open one of the affected existing projects in Codex Desktop on the Mac host and start a new conversation there, that project starts appearing in the ChatGPT Android / Codex remote project list.
• However, the older existing conversations under that same project still do not appear. Only the newly created conversation is visible.

So this does not look like the old conversations were deleted. It looks like the Android / ChatGPT remote UI is not backfilling or re-listing existing remote projects and project conversations from durable host/remote metadata. Creating a new conversation seems to refresh or create enough metadata for the project itself to become visible, but it does not restore the older conversation list for that project.

This matches the direction of this issue: the remote client appears to be missing the project/thread listing or restore path. My separately filed issue was closed as a duplicate of this one:

• #23098

I think my report is the same underlying issue, so I’m going to close it as a duplicate: https://github.com/openai/codex/issues/23351

In my case Android-created remote threads were created successfully on the Mac and showed up in Codex Desktop / CLI local history, but did not show back up in Android for resume. Threads started from the CLI had the same problem, while threads started from Codex Desktop did appear in Android.

I’m seeing the same issue on ChatGPT Android Codex Remote.

My Android app connects successfully to the macOS Codex App host , and the Mac shows the Android device as authorized/connected. However, the thread/project list on Android is stuck on an old snapshot from about 24 hours ago.

New Codex sessions created on Mac do not appear on Android. If I create a session from Android, it starts and runs locally on the Mac, but after restarting the Android app, that session disappears from the Android list while still existing on the Mac.

Also, tapping “Older chats” on Android fails with:

An error has occurred, please try again

I already tried revoking access, disabling/re-enabling remote control, closing both apps, re-pairing via QR, and reinstalling ChatGPT Android twice. The issue still persists.

So authorization/connection seems to work, but the Android remote thread history/index appears stale or broken.

This looks like a stale mobile/server-side thread index or host association, not a local macOS Codex data issue.

I’m seeing what looks like the same underlying issue, with a few extra details that may help narrow it down.

Additional observations:

• Even threads started from the ChatGPT mobile app can later disappear from the mobile UI while still existing locally on the host.
• On mobile, I can create a new thread inside the subset of projects that are visible there.
• If I leave that thread and come back later, the thread is no longer shown in the ChatGPT app, but it still exists locally in Codex state on the host.
• So the problem seems to affect both:
• loading recent host thread history, and
• re-listing / restoring mobile-created remote threads.

Recovery steps that did not fix it:

• restarting Codex Desktop
• clearing ChatGPT mobile app cache/data
• uninstalling and reinstalling the ChatGPT mobile app

Local state observations:

• Canonical local thread data still looks healthy: new threads continue to be written to the local SQLite thread DB.
• The missing threads are present locally even when the mobile app no longer shows them.
• The local derived metadata/index looks stale or regressed:
• is still stuck at a watermark / last success
• is empty

That makes this look less like an auth/pairing issue and more like a broken remote thread listing / restore path, or a stale secondary index used by the mobile UI rather than the canonical local thread store.

I am seeing the same Android Remote Control stale thread/project listing issue, with host-side evidence that the Mac has fresh local threads but Android keeps showing an old mobile snapshot.

Environment

• Host OS: macOS 26.5, arm64
• Codex Desktop: 26.519.81530 (CFBundleVersion 3178)
• Mobile: ChatGPT Android app / Codex Remote Control
• Subscription / account / workspace: redacted
• Host name shown on mobile: <redacted-mac-host>.local
• Local username and workspace paths: redacted as /Users/<local-user>/...
• Remote-control account/server/environment identifiers: redacted

What I see on Android

Android Remote Control connects to the Mac host and shows it as online, but the Codex home/list is stale:

• The project list is stuck on an old subset, for example only two old projects are shown.
• The recent thread list is stuck on a thread from about 2 days ago.
• Newer Codex sessions created/updated on the Mac do not appear on Android.
• Disconnecting/reconnecting, updating Codex Desktop, restarting the Mac, and re-opening the Android app did not refresh the list.
• The Android UI shows a spinner beside the stale list, but the visible list does not update.

This is very similar to the earlier comments saying Android can connect, but the thread/project list is stale or not restored.

Host-side evidence

On the Mac host, the canonical local thread store is current. ~/.codex/state_5.sqlite contains recent threads updated after the Android list became stale, including the current investigation thread and other active project threads.

Sanitized example from threads ordered by updated_at desc:

<thread-id-redacted> | mobile/remote stale list investigation | /Users/<local-user>/Documents/Codex/... | vscode | user | 2026-05-27 15:24:30 local
<thread-id-redacted> | active project thread | /Users/<local-user>/<workspace-redacted> | vscode/subagent | user/subagent | 2026-05-27 15:24:22 local
<thread-id-redacted> | older thread shown on Android | /Users/<local-user>/<old-project-redacted> | vscode | user | 2026-05-25 14:42:10 local

The local global state also does not match the stale Android list. The host has a different current project order and active workspace than what Android is showing. Sanitized:

project-order:
  /Users/<local-user>/<project-a-redacted>
  /Users/<local-user>/<project-b-redacted>
  /Users/<local-user>/<project-c-redacted>
active-workspace-roots:
  /Users/<local-user>/<project-a-redacted>
codex-mobile-has-connected-device: true
remote environment / installation ids: <redacted>

The remote_control_enrollments row exists and points to the same Mac host shown in Android, but its ids are redacted here:

server_name=<redacted-mac-host>.local
app_server_client_name=Codex Desktop
environment_id=<redacted-environment-id>
server_id=<redacted-server-id>
account_id=<redacted-account-id>

Log evidence

After rebooting the Mac and opening Android Remote Control again, the host successfully connects to the remote-control websocket:

connected to app-server remote control websocket: wss://chatgpt.com/backend-api/wham/remote/control/server

The backend initialize flow appears to happen, and host logs include remote-control status changes. However, around the time Android shows the stale list, I do not see Android issuing a host history/list request such as thread/list for the current home/list refresh. The logs mostly show remote status changes and local desktop/tool clients, while the Android visible list remains stuck on the older snapshot.

This matches the original report's direction: authorization/connection is working, but Android is not reliably loading/re-listing host thread history.

Recovery attempts already tried

• Updated Codex Desktop to 26.519.81530.
• Rebooted the Mac host.
• Confirmed old app-server/broker processes from before reboot are gone.
• Disconnected and reconnected the phone/host pairing.
• Reopened Android ChatGPT/Codex Remote.

The Android list still shows the same stale project/thread snapshot.

Privacy note

I intentionally redacted local username, full project names/paths, host name, account id, server id, environment id, installation id, and thread ids from this public comment. I can provide more specific diagnostics privately if maintainers need them.

Thread history does seem broken for me - newly created threads on desktop also do not show up in the remote app for me on Android.

I am seeing the same Android Remote Control stale thread list / missing restore problem, with one additional failure mode: Android-created test threads can disappear from mobile after refresh/reopen and do not show up as an obvious new persisted thread in the host thread list.

Environment

• Host: macOS 26.5.0, arm64
• Codex Desktop: 26.519.81530 (CFBundleVersion 3178)
• Host app-server version from remote-control metadata: 0.133.0
• Mobile: Android 16, device model PTP-AN00
• ChatGPT Android app version: 1.2026.125
• Same account on desktop and Android

Current behavior

Android Remote Control connects to the Mac host and the backend shows the Mac environment as online. However, the Android Codex thread list is stale:

• Recent threads from the last few days are visible in Codex Desktop but do not appear on Android.
• Logging out/in, refreshing, and reopening Android ChatGPT did not refresh the list.
• If I create a new Codex thread from Android, it appears temporarily, but after refresh/reopen it disappears from Android.
• After that disappearance, I could not find an obvious corresponding Android-created test thread in the host's current local ~/.codex/state_5.sqlite threads list, while desktop-created recent threads are still present there.

Host/backend observations

• The host's canonical local thread store is current: recent desktop threads are present in ~/.codex/state_5.sqlite, ordered by updated_at.
• The backend remote-control environment endpoint shows the Mac host online and recently seen.
• The backend remote-control clients endpoint shows one Android client with enrolled_device_key, but also multiple recent pending_enrollment entries for the same Android device/app version from repeated reconnect/authorization attempts.
• Desktop logs show remote control being enabled, but the visible mobile list still remains stale.

This makes it look less like local thread data loss and more like a Mobile Remote thread index / restore / listing issue. The connection and authorization path can partially work, but the mobile list does not reliably converge to host state, and Android-created threads may not be safely restored after the mobile list refreshes.

Related symptoms look similar to #24462 and #22800.

I ran into a very similar issue on macOS + Codex Desktop + ChatGPT/Codex mobile remote control, and I was able to recover it locally. Sharing the details
in case it helps narrow this down.

Environment:

• Host: macOS
• Codex Desktop: 26.519.81530, build 3178
• Codex state dir: ~/.codex
• Mobile client: ChatGPT/Codex mobile remote connection

Symptoms:

• Mobile could start a new short conversation.
• The new conversation was visible while active / immediately after completion.
• After restarting the mobile app, that new conversation disappeared from the mobile history list.
• The local host still had the thread in ~/.codex/state_5.sqlite.
• The corresponding rollout JSONL file also existed under ~/.codex/sessions/....
• One older mobile-visible thread was stuck spinning and could not be deleted/archived from mobile. The toast said:

```text
no rollout found for thread id <redacted-thread-id>

  In my case SQLite itself was healthy:

  sqlite3 ~/.codex/state_5.sqlite 'PRAGMA quick_check; PRAGMA integrity_check;'
  sqlite3 ~/.codex/logs_2.sqlite 'PRAGMA quick_check; PRAGMA integrity_check;'

  Both returned ok.

  The important local findings were:

  1. A newly created mobile thread was present locally, for example:

  id=<redacted-thread-id>
  title=hi
  source=vscode
  thread_source=''
  archived=0
  rollout_path=~/.codex/sessions/2026/05/28/rollout-...jsonl

  2. Many normal user threads had an empty thread_source:

  select coalesce(nullif(thread_source,''),'<empty>') as thread_source,
         count(*) as n,
         max(datetime(updated_at,'unixepoch','localtime')) as newest
  from threads
  group by coalesce(nullif(thread_source,''),'<empty>')
  order by n desc;

  Before repair I had roughly:

  <empty> 181
  user    119
  subagent 112

  3. remote_control_enrollments had two rows for the same account + host. One had an empty app_server_client_name, and one was an older Codex Desktop
     enrollment:

  app_server_client_name=''              environment_id=<new-env-id>
  app_server_client_name='Codex Desktop' environment_id=<old-env-id>

  4. ~/.codex/.codex-global-state.json still pointed at the older environment id:

  electron-local-remote-control-environment-id=<old-env-id>

  What fixed it for me:

  First, I fully backed up the affected files:

  - ~/.codex/state_5.sqlite*
  - ~/.codex/logs_2.sqlite*
  - ~/.codex/.codex-global-state.json
  - ~/.codex/session_index.jsonl

  Then I verified that every thread I was going to touch had an existing rollout_path.

  The minimal DB repair was:

  - For normal user threads only:
      - source='vscode'
      - archived in (0,1)
      - thread_source is null or thread_source=''
      - rollout file exists

  set:

  thread_source='user'

  I did not modify subagent / automation / mcp / exec threads.

  In my case this updated 103 rows. created_at_ms and updated_at_ms were already populated, so I did not need to backfill those.

  For the remote-control side, I conservatively cleared only the conflicting remote-control state:

  - deleted the duplicate/stale rows from remote_control_enrollments for this account + host;
  - removed only these keys from ~/.codex/.codex-global-state.json:

  codex-mobile-has-connected-device
  electron-local-remote-control-environment-id
  electron-local-remote-control-installation-id

  I did not delete ~/.codex, did not delete sessions/, and did not delete archived_sessions/.

  After restarting Codex Desktop and re-pairing mobile remote control, the issue was resolved:

  - existing local history became visible correctly;
  - a newly created hi conversation stayed visible after force-restarting the mobile app;
  - the repaired thread now had thread_source='user'.

  My guess is that there are two related failure modes here:

  1. older or migrated user threads can be locally valid but filtered out by the mobile/remote history path because thread_source is empty;
  2. stale or conflicting remote-control enrollments can leave mobile connected to an inconsistent environment id / local remote state.

  So the host may have all the correct rollout data, but the mobile list path still fails because the derived metadata and/or remote enrollment state is
  inconsistent.

  This is only a local workaround, not a recommended official repair procedure. But it may help explain cases where:

  - state_5.sqlite contains the thread;
  - rollout_path exists;
  - mobile still drops the conversation from history after restart;
  - re-login / app restart / re-pairing alone does not fix it.

It seems that the issue is solved. I'm on Linux and my Codex is 0.137.0. When I open my Android ChatGPT app and go to the Codex page, the chat history is rendered correctly.

It looks like it's also solved for me.

definitely solved

Closing as resolved.