Local threads exist in SQLite but disappear from ChatGPT mobile; duplicate local host entries
Bug: local threads exist in SQLite but do not appear in ChatGPT mobile; duplicate local host entries also appear
Summary
Local Codex threads are being written correctly on desktop, but many recent local threads do not appear in the ChatGPT mobile app even though remote control is connected and healthy.
At the same time, the ChatGPT mobile app shows two connections for the same local machine.
Version
- Codex desktop version metadata:
0.133.0
What I expected
- Local threads created on the desktop should appear in the ChatGPT mobile app if that surface is supposed to expose the current local thread list.
- The mobile app should show a single connection entry for the local Mac unless there are intentionally distinct host identities.
What happened
- New local threads continue to appear in the primary local thread store, but many do not show up in the ChatGPT mobile UI.
- I can still create new threads from the ChatGPT mobile app, but only for the subset of projects that already show up there.
- If I leave that mobile-created thread and come back later, it disappears from the ChatGPT app UI and seems to survive only in local Codex state on desktop.
- The mobile app shows two connections for the same host:
Codex Desktoppaseo- both mapped to the same local Mac host
Repro
- Use Codex Desktop normally and create new local threads.
- Confirm the threads exist locally.
- Open ChatGPT mobile and check the connected/local thread surface.
- Observe that only some projects appear there.
- Create a new thread from mobile inside one of those visible projects.
- Leave the thread and return later.
- Observe that the thread no longer appears in the ChatGPT mobile UI, but the local desktop state still contains the thread.
- Also observe that the newest local desktop threads do not appear.
- Observe that the same local Mac appears twice as two separate connections.
Evidence
Primary local thread store is current
Local thread database:
threadscount:2042- latest thread timestamp:
2026-05-25 13:30:56 UTC
This includes threads that were visible transiently from mobile and later stopped appearing there.
Examples of recent missing threads:
- a thread created on
2026-05-25during investigation of this issue - another thread created on
2026-05-25from mobile/Codex workflow testing
Most recent thread still visible in the ChatGPT app:
- one thread from a website project
- created at
2026-05-21 19:59:32 UTC - last updated at
2026-05-24 05:31:34 UTC
So the visibility cutoff may depend on either creation time or last activity time; both are worth checking.
Remote/mobile connection looks healthy
Global state:
codex-mobile-has-connected-device = trueremote-project-connection-backfill-completed = true
Remote control enrollments:
Codex Desktop-> same local Mac hostpaseo-> same local Mac host
Derived metadata appears stale or regressed
Global state file:
thread-titles = { "titles": {}, "order": [] }projectless-thread-idscount:48thread-workspace-root-hintscount:220
backfill_state in the local state database:
- status:
complete - last watermark:
sessions/2026/02/26/rollout-2026-02-26T15-32-57-019c9b39-ba66-7862-88f9-f1332e4fcd5e.jsonl- last success:
2026-02-27 04:15:26 UTC
That looks stale relative to current thread activity in late May 2026.
Quantified mismatch
For threads under one local Codex workspace root updated after 2026-03-01:
- total in SQLite:
94 - missing from
thread-workspace-root-hints:46
This also reproduces across multiple local projects, not just one specific repo.
This suggests the canonical thread rows are being written, but the companion metadata layer used for higher-level listing/grouping is not being kept up to date.
Notes
- Restarting the Codex desktop app did not fix the issue.
- Clearing ChatGPT mobile app cache and app data did not fix the issue.
- Uninstalling and reinstalling the ChatGPT mobile app did not fix the issue.
- The bug is not just "old local threads do not sync into mobile". Even threads created from the mobile app itself can disappear from the ChatGPT app later while still existing locally.
- This does not look like an auth/pairing problem.
- This does not look like a raw thread-write failure.
- It looks more like a stale index/backfill path or a metadata migration/regression.
Suspected root cause
The app appears to have:
- a canonical thread store that is still healthy, and
- a separate derived metadata/index layer for project/thread presentation
The canonical store is current, but the derived layer seems stale or no longer maintained correctly.
The duplicate host entries may be a related enrollment cleanup bug, where revoked/relinked or renamed local identities are not deduplicated.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗