Mobile Remote briefly shows a local project/thread, then removes both after sync

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

• #24447
• #23152
• #23952
• #24271
• #24454

Powered by Codex Action

Additional clean-project control test:

I created a brand-new local git repository solely for this test, with these properties:

• one empty initial commit on main
• no remote configured
• no .codex environment configuration
• no pre-existing Codex thread history

I opened that new repository in Codex Desktop, created a new thread (Remote visibility clean project probe), and observed the same behavior on mobile: the new project/thread appeared briefly, then disappeared.

This rules out the original workspace's repository metadata, existing thread history, remote URL, and custom environment configuration as necessary conditions for the bug. The behavior appears to affect newly added local projects on this Desktop Remote connection generally.

Additional existing-visible-project control test:

I created a new thread (Remote visibility existing visible project probe) inside an existing project that is already persistently visible on mobile.

Result:

• the existing project remained visible on mobile
• the newly created thread appeared briefly, then disappeared

Combined with the clean-project test above, this narrows the issue to persistence/indexing of newly created threads on Mobile Remote. A brand-new project also disappears because its only newly created thread is removed from the mobile index, while an older project remains listed because it already has persistently visible historical content.

This appears closely aligned with #23152 (Mac-visible recent project threads missing from the mobile thread list/search).

Additional mobile-created-thread control test:

I created a new thread from Codex Remote on mobile inside a project that is already visible on mobile.

Result:

• the mobile-created thread appeared briefly on mobile, then disappeared from the mobile thread list
• the same thread successfully appeared and remained visible in Codex Desktop

This rules out a Desktop-to-mobile thread upload-only failure. New thread state can successfully synchronize to Desktop even when created on mobile, but the mobile persistent thread list still removes it shortly afterward. The failing layer is most likely mobile/backend persistent thread enumeration or refresh filtering for newly created Remote threads.

Additional mobile reinstall control test:

I uninstalled and reinstalled the ChatGPT mobile app, signed back into the same account, and repeated the Codex Remote test.

Result:

• a newly created thread still appeared briefly on mobile and then disappeared
• the same thread remained visible in Codex Desktop

Reinstalling the mobile client did not change the behavior. This makes a stale mobile app cache or corrupted local installation unlikely, and further supports a persistent Mobile Remote thread-list/index refresh issue outside the local project configuration.

Related issue: #22762 documents that Android Remote Control connects to Codex Desktop but host logs show initialize and thread/start only, with no observed thread/list or thread/loaded/list request for persisted history.

My results appear consistent with and extend that report:

• new threads are delivered live and briefly rendered on mobile, then disappear
• this occurs for both desktop-created and mobile-created Remote threads
• the threads remain present in Codex Desktop
• reinstalling the ChatGPT mobile app does not change the outcome

Together, these results suggest live thread events work, while persisted Mobile Remote thread enumeration/list refresh does not load or retain newly created threads.

I ran into the same issue. Below is the analysis/debugging that Codex produced, fully tracing it back to the bounded rollout-preview scan in codex-rs/rollout/src/list.rs.

The missing threads were valid, unarchived, and present in state_5.sqlite. A state-backed thread/list returned all of them, while the normal updated_at listing omitted them.

The affected legacy rollouts begin with an IDE placeholder ending in ## My request for Codex:. Prefix stripping produces an empty preview, while the first substantive user message occurs beyond the 210-record scan limit (HEAD_RECORD_LIMIT = 10 plus USER_EVENT_SCAN_LIMIT = 200). build_thread_item() requires summary.preview.is_some(), so it silently drops the otherwise-valid thread. When every thread for a workspace is dropped, the project disappears too.

Codex verified the cause on an isolated copy: the normal listing initially returned zero threads; adding a recognized preview-bearing event near the beginning made the identical query return the thread. Applying that metadata-only repair to six unloaded rollouts made all six immediately reappear on iOS without restarting Codex.

The fix should be to retain valid sessions when the bounded scan cannot find a preview, falling back to the state-database title/preview or continuing until a substantive user message is found.

I reproduced this on a real affected thread with the Codex app's bundled CLI 0.145.0-alpha.18. The host logs identified the iOS Remote client as 1.2026.188.

The thread behaved differently in two otherwise identical app-server requests:

thread/list useStateDbOnly=true   -> present
thread/list useStateDbOnly=false  -> absent

The request used archived: false, limit: 100, and sortKey: "updated_at". Omitting useStateDbOnly produced the same omission as false. thread/read still worked, the rollout parsed without errors, and the thread was active and unarchived.

The first persisted user event was at line 11. It was an attachment-only app wrapper ending with an empty ## My request for Codex: section. strip_user_message_prefix() therefore returned an empty string. The next user event with usable preview text was at line 394, beyond HEAD_RECORD_LIMIT + USER_EVENT_SCAN_LIMIT.

I backed up the rollout and added the actual request text after the empty marker in the matching response_item and event_msg records. Those were the only two changed lines. The same normal thread/list request then returned the thread, and the thread remained visible on iOS after the list finished refreshing.

This appears to be the same underlying bug reported in #24077 and #21619. A missing preview should lower the quality of the list row, not remove an otherwise valid and resumable thread.

Current main still checks summary.saw_session_meta && summary.preview.is_some() in codex-rs/rollout/src/list.rs and filters SQLite rows with threads.preview <> '' in codex-rs/state/src/runtime/threads.rs.

The patch shared in #21619, commit 24b5388636, removes both eligibility checks and adds rollout and state DB regression tests. I think an app-server integration test would also help. It could start with an attachment-only message whose request section is empty, place the next substantive user event beyond the scan limit, and assert that the normal and state-only list paths return the same thread ID.

I did not open a PR because the contribution guide says external code contributions require an invitation. Could a maintainer adopt that patch direction or invite a targeted PR?