Codex mobile thread list loses visibility after desktop resume on same host

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

• #24462
• #24447
• #23152
• #24454
• #23351

Powered by Codex Action

Same here on Android Codex mobile... I miss recent sessions. I can only see sessions 20 hours- 2 days prior to current moment and earlier. Recent sessions missing.

This looks like a host/session projection problem more than plain thread sync.

For the mobile thread list I would want each row to carry enough provenance to explain why it is visible:

• host id
• workspace or project root
• local conversation/session id
• app-server or process generation
• last turn cursor observed by desktop
• last turn cursor observed by mobile
• latest activity source: mobile, desktop, or CLI
• visibility state: live, stale, desktop-only, or mobile-index-missing

If desktop resumes a mobile-started thread, the mobile row should not disappear. The safer degraded state is something like: desktop advanced to cursor X, mobile index is still at cursor Y, reconnect or refresh needed. That distinguishes "thread no longer exists" from "mobile projection is stale."

This is the same boundary I have been using in Faryo: the mobile/browser surface is only a projection unless it can prove which live host session and cursor it is attached to. Faryo keeps the tmux session as the live source of truth and treats the mobile workbench as a control surface over that session:
https://github.com/Snailflyer/faryo

I can reproduce a closely related case on macOS with ChatGPT mobile Remote:\n\n- A task started from the phone against the connected Mac host exists and completes on the host.\n- The task can be opened/read on the Mac by its thread ID, but it is absent from the phone's Remote task list.\n- The host-side task metadata is local to the connected Mac, which is expected for Remote, but the mobile Remote list does not retain/show the task.\n- Reopening/pinning the task on desktop does not make it appear on mobile.\n\nThis makes the task look lost even though the transcript still exists on the host. Expected behavior: a mobile-created Remote task should remain discoverable and resumable from the same phone/host pair after completion and after desktop activity.\n\nThis appears to match the mobile-only visibility/state-sync issue described here.

Independent reproduction on 2026-07-18 using the ChatGPT iOS Codex Remote view connected to an online Mac host.

Observed sequence:

1. A project-backed thread titled Analyze Sitexo ui-content model was active and initially visible in the iOS Remote task list.
2. While it was running, thread metadata reported it as active/in progress.
3. After its latest turn completed successfully, the thread changed to idle.
4. The thread then disappeared from the iOS Remote list under Today and could no longer be found by its exact title.
5. A direct read using the already-known thread ID still succeeds and returns the correct title, project workspace, completed latest turn, and idle status.
6. Re-querying the normal recent-thread list later omitted the thread entirely, while direct lookup continued to work.

Expected: a completed/idle, project-backed thread on the same connected host should remain visible and searchable from iOS Remote.

Actual: the thread data remains intact and addressable by ID, but the mobile list/search discovery path drops it after completion.

This reproduction did not require resuming the thread on desktop. It also differs from projectless-thread reports: the affected thread has a project association. The connected host remained online throughout. A screenshot of the iOS Remote list showing the missing thread was captured and can be provided if useful.

No full thread ID, logs, repository contents, credentials, or private conversation data are included here.

Windows/Android confirmation with local metadata evidence

I reproduced the same mobile-only visibility loss on Windows 11 with ChatGPT Android Remote connected to Codex Desktop.

Environment

• Windows 11
• Codex Desktop app/server client: 26.721.41059
• Microsoft Store package: 26.721.4979.0
• Bundled CLI/app server: 0.146.0-alpha.3.1
• ChatGPT Android -> Codex Remote connected to the Windows desktop

Observed sequence

1. A local-project thread was created from Android Remote and initially worked normally.
2. The same thread was continued for a long time on Codex Desktop.
3. On Android Remote, other threads from the same connected desktop remained visible, but this one thread was absent.
4. This was confirmed while the affected thread was active and unarchived, so archive state was not the original cause.
5. The user later accidentally archived the active thread on Desktop. The backend archive succeeded and moved the rollout to archived_sessions, but the thread was also absent from Desktop Settings -> Archived chats.

Read-only local evidence captured before remediation

• The rollout JSONL existed and was intact: 1,514 records, 0 JSON parse errors, about 10.3 MB.
• The thread row existed in state_5.sqlite.
• source = 'vscode'
• thread_source = NULL
• name = NULL
• title, preview, and first_user_message were all the same 5,184-character fallback first prompt instead of a normal short title/preview.
• The thread had no entry in session_index.jsonl.
• Other directly visible user threads on the same installation generally had thread_source = 'user' (or automation where appropriate).

This makes the incident look like metadata/classification and list-filtering drift, not transcript deletion.

Local recovery performed

After making an online SQLite backup plus copies of the rollout and session index, I:

• restored the accidental archive to archived = 0;
• normalized thread_source to user;
• assigned a short name / title / preview;
• restored a session_index.jsonl entry.

Post-repair checks show SQLite quick_check = ok; all 1,514 rollout records still parse with 0 errors. UI re-listing after a full app/Remote refresh is still being verified.

Expected behavior

• A Remote-created direct user thread should persist with thread_source = 'user'.
• It should remain discoverable on mobile after Desktop resumes it.
• If archived, it should appear in Desktop Archived chats.
• A valid rollout with missing classification/index metadata should be surfaced in a fallback view or repaired automatically, rather than appearing to be lost.

The archive click in this incident was accidental and secondary. The primary regression occurred before that: the active thread disappeared only from Android Remote after Desktop activity.

This appears related to #23418, where another Remote-created thread also had thread_source = NULL, but the user-visible direction here matches this issue: Mobile-created -> visible on Desktop -> continued on Desktop -> missing on Mobile.

Thread IDs, account identifiers, filesystem paths, screenshots, network details, and conversation contents are intentionally omitted.

Additional reproducible evidence from macOS Codex Desktop + ChatGPT mobile Remote on August 11, 2026:

• The affected thread is project-backed; it has a valid projectId, repository cwd, and remains unarchived.
• The local rollout/session and session_index.jsonl entry are intact.
• Exact thread-ID navigation opens the correct thread on desktop.
• The normal recent-thread inventory omits it, while the title/search index can still resolve it.
• The affected thread was renamed. It shares the same original first-message preview and project/cwd with another thread that remains visible, suggesting the recent-list materialized view may be deduplicating by stale title/preview metadata rather than thread ID.
• Rewriting the title did not restore durable visibility.
• A pin -> unpin cycle temporarily increased the recent list count and restored the thread, but it disappeared again later.
• Pinning it permanently returned success, yet the thread was still absent from the next recent-list query.
• The connected host remained available; the unavailable-host list was empty.
• Restarting and refreshing the mobile app did not restore it.

Expected: each project-backed thread should be catalogued by stable thread ID, remain discoverable in mobile Remote while idle, and honor pinned state. A stale title/preview or duplicate initial prompt should never hide an intact thread.

This looks like persistent drift between the thread/search index and the recent-list projection, not transcript loss, account mismatch, or a temporarily offline host. Identifiers, repository paths, and conversation content are omitted but can be provided privately.