Android Remote thread/list omits agent-created threads and returns duplicate IDs; early user event restores visibility

Summary

Android Remote omits valid desktop threads before rendering: a captured thread/list response from the Mac was already incomplete and contained duplicate IDs. A controlled A/B/A test shows that inserting an original task assignment as an early event_msg.user_message restores one affected thread to the filesystem listing. This also restored access on the actual phone.

Related: #22777 (early preview scan), #25589 (iOS empty listing), #24749 (Android visibility). This report adds recent-version reproduction, duplicate counts, and a verified mobile workaround. It does not establish that all of these reports share one cause.

Environment

• macOS host, Desktop 26.901.31953 (7868)
• Bundled codex-cli/app-server 0.153.1
• Android client version documented during this investigation: 1.2026.237 (16)
• Local desktop threads, ChatGPT/OpenAI provider
• Investigation: September 4–5, 2026
• Earlier symptoms reproduced on two Android phones; reconnecting/re-pairing did not resolve them

Host-side evidence

The captured mobile request used thread/list, limit 50, updated_at descending, cursor null. No useStateDbOnly appeared in the retained parameters. Capture retained selected parameters and response metadata, not complete raw traffic.

The host replied with:

• 25 records but only 14 unique thread IDs
• nextCursor: null
• Only 2 threads from a local project with 20 non-archived root vscode threads in SQLite

Thus this particular omission cannot be explained solely by Android hiding correctly received records. Duplicate multiplicities matched the number of JSONL history files for the affected IDs; those files may be legitimate history continuations.

On an isolated copy, using the installed binary:

• useStateDbOnly: false reproduced 25 records / 14 unique / 2 project threads.
• useStateDbOnly: true returned 17 unique / 4 project threads.
• Filling one empty preview in the copied state DB restored that thread only to the SQLite listing. The filesystem listing remained unchanged.

Controlled reproduction / workaround

For one completed agent-created thread, its original assignment was recovered from the parent create_thread call and matched to the returned child ID.

In an isolated copy, insert one event_msg.user_message containing that assignment immediately after session_meta, without altering the rest of the JSONL:

In separate control/patched copies, thread/read, full thread/turns/list, and thread/resume succeeded. The returned 289 history items matched by canonical JSON hash before/after resume and between copies. No new model turn was run.

After backing up and applying this one-thread workaround on the real host, the user confirmed both visibility and opening the original final answer on Android. This is a workaround, not evidence that rewriting histories is a supported repair.

Creating a thread through an agent is a correlation, not a sufficient condition

Of 34 agent-created/forked threads compared with mobile screenshots:

• 3 were visible without repair and had user messages.
• 1 became visible through the workaround above.
• 30 were absent. Of those, 27 had no projected userMessage, but 3 had a real user follow-up in a second turn and still did not appear.

Therefore “send one message” is not yet a proven general workaround.

Separate project-list observation

Android project groups matched working-directory names rather than Desktop display names/icons. Archiving the last visible user thread in each of two otherwise unsaved desktop folders immediately removed both mobile groups. Renaming another working directory and updating its references eventually changed the mobile group name, while its Desktop display name stayed unchanged.

This supports grouping by thread working directories, but we have not inspected Android implementation. It may need a separate issue.

Expected behavior

Valid threads should not be silently excluded solely because a filesystem preview scan misses a user event when their history/metadata exists elsewhere. Listings should deduplicate logical thread IDs across history segments and provide complete pagination.

Please investigate the default filesystem scan/repair listing versus the state-DB-only path, particularly agent-created and paginated histories. No private paths, thread IDs, raw logs, or conversation contents are attached.

Start at the host-side thread/list entry point and compare the default filesystem scan/repair listing with useStateDbOnly: true, using the captured 25-record/14-unique response as the regression case. Trace how agent-created histories and paginated results are assembled, and inspect thread/read, thread/turns/list, and thread/resume behavior. Done means valid histories are listed once by logical thread ID with complete pagination, without relying on an inserted event_msg.user_message.