Android Remote loses completed Android-created threads after refresh/reconnect while desktop-created threads persist

What version of the Codex App are you using?

• Codex Desktop: 26.721.4979
• Bundled Codex CLI/app-server: 0.146.0-alpha.3.1
• Host OS: Windows x86_64
• Mobile client: ChatGPT Android Codex Remote, identified in app-server logs as codex_chatgpt_android_remote (client_version="dev")

The desktop app was launched through a third-party compatibility launcher that provides custom-provider routing. The Android Remote connection and thread lifecycle RPCs are handled by the official bundled Codex app-server. The affected turn completed successfully, so this report is about mobile thread persistence rather than model transport failure.

What subscription do you have?

ChatGPT account login is active. The model request was routed through a configured Responses-compatible provider.

What platform is your computer?

Windows x86_64.

What issue are you seeing?

A thread created from ChatGPT Android Remote completes successfully and remains present on the Windows Codex Desktop host, but later disappears from the Android recent-thread list after an ordinary refresh/reconnect.

This reproduction does not require force-quitting Android while the assistant turn is still running:

• The Android-created turn reaches task_complete normally.
• The model request completes successfully.
• The thread remains visible and usable on the desktop host.
• The thread later disappears from Android history.

By contrast, a thread created from Codex Desktop remains visible on Android normally.

Steps to reproduce

1. Connect ChatGPT Android Codex Remote to a running Windows Codex Desktop host.
2. From Android, create a new thread and send a short prompt.
3. Wait until the assistant reply and turn complete normally.
4. Confirm that the thread is present on the Windows desktop host.
5. Refresh/reconnect the Android Codex Remote surface or wait for its recent-thread list to refresh normally.
6. Observe that the Android-created thread disappears from Android history.
7. Create another thread from Codex Desktop.
8. Observe that the desktop-created thread remains visible on Android.

No force quit during an active turn is required for this reproduction.

Expected behavior

A successfully completed Android-created thread should remain visible on Android after refresh/reconnect, just like a desktop-created thread, while it remains present on the connected host.

Actual behavior

• Android-created completed thread: disappears from Android after refresh/reconnect.
• The same thread: remains present and usable on Windows Codex Desktop.
• Desktop-created thread: remains visible on Android.

Host-side evidence

For the disappearing Android-created thread:

• The rollout contains the complete lifecycle:

session_meta -> task_started -> user_message -> assistant output -> token_count -> task_complete.

• The state DB row has archived = 0 and has_user_event = 1.
• There was no corresponding model, sampling, or transport failure.
• The Android client does issue thread/list after reconnect in this build.
• Running the same official bundled codex app-server against an isolated copy of the host state returns the Android-created thread from thread/list.

A consistent metadata difference was observed:

• Desktop-created thread: threadSource = "user"
• Android-created thread: threadSource = null

An isolated official app-server experiment confirmed:

• thread/start without threadSource returns and persists threadSource: null.
• thread/start with threadSource: "user" returns threadSource: "user".

This difference may be relevant to Android's recent-thread reconstruction, but it is only a hypothesis; the host app-server can still return the affected thread from thread/list.

A DB-only repair was not effective: changing the SQLite thread_source column did not change the app-server response, which continued to derive threadSource: null from the original rollout metadata. No production rollout files were modified.

Difference from related issue

Possibly related to #22800, but this is a different reproduction:

• #22800 describes force-quitting Android while an Android-created turn is still active.
• This report concerns an Android-created thread that has already completed successfully and disappears after an ordinary refresh/reconnect without that force-quit condition.

Additional information

All thread IDs, transcript text, local paths, provider URLs, and credentials have been omitted. Sanitized request sequencing can be provided if useful.