Skip to content

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

Closed
Closed
Android Remote Control does not load host thread history (no thread/list requests observed)#22762
Labels
bugSomething isn't workingremote

Description

@hekunwang
hekunwang
opened on May 15, 2026

Summary

When using ChatGPT Android → Remote Control → connect to a Mac running Codex Desktop, the mobile UI does not show any existing host conversation history (local/persisted threads). The host appears to receive the connection, but the Android remote client never issues thread/list (or thread/loaded/list) to the host app-server, so there is nothing to render.

As a result, Remote Control on mobile looks like it has “no remote threads loaded” / cannot load history.

Environment

  • Host: macOS 26.3 (Build 25D125), Darwin 25.3.0 arm64
  • Codex Desktop: 26.513.20950 (CFBundleVersion 2816)
  • Bundled CLI: codex-cli 0.131.0-alpha.9
  • Codex home: ~/.codex

What I expected

After Android Remote Control connects to the host, the mobile UI should be able to display host thread history by calling:

  • thread/list (persisted history) and/or
  • thread/loaded/list (in-memory loaded threads)

What actually happens

From host-side logs (~/.codex/logs_2.sqlite), Android remote connections only call:

  • initialize
  • thread/start

No thread/list, thread/loaded/list, thread/read, or thread/resume is observed from the Android remote client, so persisted threads never appear on mobile.

Evidence (host logs)

I queried ~/.codex/logs_2.sqlite for the Android remote client name codex_chatgpt_android_remote.

Observed methods (deduped):

  • rpc.method="initialize" / client_name="codex_chatgpt_android_remote"
  • rpc.method="thread/start" / client_name="codex_chatgpt_android_remote"

No entries for:

  • rpc.method="thread/list"
  • rpc.method="thread/loaded/list"

Example log line (redacted/truncated):

app_server.request{... rpc.method="thread/start" ... app_server.client_name="codex_chatgpt_android_remote" ...}

Additional notes

  • The host has many local threads in ~/.codex/state_5.sqlite and thread/list works when called locally.

Repro steps

  1. On Mac, open Codex Desktop and ensure Remote Control is enabled.
  2. On Android ChatGPT app, open Remote Control and connect to the Mac host.
  3. Observe that mobile Remote Control does not show host history.
  4. Check host logs (~/.codex/logs_2.sqlite): only initialize + thread/start from codex_chatgpt_android_remote.

Suspected cause

Mobile Remote Control UI may not be issuing thread/list at all (or the request is being filtered client-side by sourceKinds such that it never reaches the host).

Activity

  1. etraut-openai
    added
    bugSomething isn't working
    remote
    on May 15, 2026

  2. hekunwang commented on May 16, 2026

    @hekunwang
    hekunwang
    on May 16, 2026
    Author

    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:

    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.

  3. heyyymonth
    marked Android ChatGPT app does not show remote Codex threads from macOS Codex app #23070 as a duplicate of this issue on May 16, 2026
  4. musnows
    marked ChatGPT app Codex remote only shows projects after starting a new conversation #23098 as a duplicate of this issue on May 17, 2026

  5. musnows commented on May 17, 2026

    @musnows
    musnows
    on May 17, 2026

    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:

  6. bwong365 commented on May 19, 2026

    @bwong365
    bwong365
    on May 19, 2026

    I think my report is the same underlying issue, so I’m going to close it as a duplicate: #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.

  7. generalsvr commented on May 25, 2026

    @generalsvr
    generalsvr
    on May 25, 2026

    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.

  8. brenorb commented on May 25, 2026

    @brenorb
    brenorb
    on May 25, 2026

    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.

  9. Adonis0123 commented on May 27, 2026

    @Adonis0123
    Adonis0123
    on May 27, 2026

    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.

  10. Techie5879 commented on May 27, 2026

    @Techie5879
    Techie5879
    on May 27, 2026

    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.

  11. fei-bai-s commented on May 28, 2026

    @fei-bai-s
    fei-bai-s
    on May 28, 2026

    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.

  12. shiyw commented on May 28, 2026

    @shiyw
    shiyw
    on May 28, 2026

    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:
    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=
    title=hi
    source=vscode
    thread_source=''
    archived=0
    rollout_path=~/.codex/sessions/2026/05/28/rollout-...jsonl

    1. Many normal user threads had an empty thread_source:

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

    Before repair I had roughly:

    181
    user 119
    subagent 112

    1. 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=
    app_server_client_name='Codex Desktop' environment_id=

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

    electron-local-remote-control-environment-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.

  13. toku-sa-n commented on Jun 6, 2026

    @toku-sa-n
    toku-sa-n
    on Jun 6, 2026

    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.

  14. brenorb commented on Jun 11, 2026

    @brenorb
    brenorb
    on Jun 11, 2026

    It looks like it's also solved for me.

  15. colonelpanic8 commented on Jun 11, 2026

    @colonelpanic8
    colonelpanic8
    on Jun 11, 2026

    definitely solved

  16. ax-openai commented on Jun 12, 2026

    @ax-openai
    ax-openai
    on Jun 12, 2026 – with ChatGPT Codex Connector

    Closing as resolved.

  17. ax-openai
    closed this as completedon Jun 12, 2026

  18. boombx403-byte commented on Aug 18, 2026

    @boombx403-byte
    boombx403-byte
    on Aug 18, 2026

    Hi @hekunwang, I'm testing a local-first, read-only diagnostic tool (Codex Rescue Alpha5) against local session persistence and rollout anomalies. It evaluates schema compatibility, tool correlation, and state consistency without modifying the original rollout or SQLite databases.

    If the affected session is still present locally, you can run:

    pip install codex-rescue==0.1.0a5
codex-rescue doctor --latest

    No raw data is needed; please redact any private repository paths before sharing results.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingremote

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions