codex - 💡(How to fix) Fix Remote mobile-started and CLI-started threads are not listed in the mobile app for resume

What version of the Codex App are you using (From “About Codex” dialog)?

26.513.31313 (CFBundleVersion 2867)

Codex CLI/app-server observed locally: codex-cli 0.131.0-alpha.9 in the app-server logs. The shell codex --version currently reports codex-cli 0.130.0, so there may be a Desktop-bundled app-server version difference.

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.4.0 arm64 arm

Mobile client: ChatGPT mobile Codex remote surface on Android was used for the main reproduction. The same symptom was also observed when checking mobile visibility after pairing/reconnecting.

What issue are you seeing?

A Codex thread started from the ChatGPT mobile Codex remote surface is created and usable locally, and it appears in Codex Desktop and the Codex CLI local history, but it does not appear in the ChatGPT mobile Codex remote conversation list afterward, so it cannot be resumed from mobile. Threads started from Codex CLI also do not appear, and therefore cannot be resumed. Threads created in the same project from the Codex Desktop app do appear.

The local state does not appear to be missing or corrupt:

• The problematic threads exist in ~/.codex/state_5.sqlite.
• Codex Desktop and Codex CLI can see them locally.
• Editing local SQLite fields that differ from a Desktop-created thread did not make them appear on mobile.
• The local Desktop Chromium cache shows the backend task-list endpoint returning an empty current-task list:

{"items":[],"cursor":null}

for:

https://chatgpt.com/backend-api/wham/tasks/list?limit=20&task_filter=current

This makes it look like a backend/mobile task-indexing problem rather than a local SQLite/thread-store problem: the remote mobile start reaches the local app-server and creates a local thread, but the resulting thread does not become a backend WHAM task that mobile later lists.

A comparison between a Desktop-created thread that is visible on mobile and a mobile-started thread that is not visible on mobile showed these local differences:

Desktop-created visible thread:

thread_id: 019e3364-4cae-7ea0-9f5a-154822df95ea
client_name in logs: Codex Desktop
source: vscode
thread_source: user
reasoning_effort: medium
dynamic_tool_count: 3

Mobile-started missing thread:

thread_id: 019e337a-1748-70d0-abd4-69ce629867fb
client_name in logs: codex_chatgpt_android_remote
source: vscode
thread_source: NULL
reasoning_effort: NULL
dynamic_tool_count: 0

I tested local SQLite changes one at a time against the missing mobile-started thread:

• set thread_source from NULL to user
• set reasoning_effort from NULL to medium
• copied the three thread_dynamic_tools rows from the Desktop-created visible thread

None of those made the thread appear in mobile. The experiments were reverted afterward.

Relevant local log shape for the mobile-started thread:

app_server.request otel.name="thread/start"
rpc.method="thread/start"
app_server.client_name="codex_chatgpt_android_remote"
thread_start.dynamic_tool_count=0
thread_start.persist_extended_history=false
thread_id=019e337a-1748-70d0-abd4-69ce629867fb

The first user turn for that thread then runs normally through the local app-server and responses path. Local logs also show auth_mode="Chatgpt" and originator=Codex_Desktop, but account id, email, hostname, and local project path are omitted here.

What steps can reproduce the bug?

1. Pair ChatGPT mobile with Codex Desktop remote control.
2. From ChatGPT mobile, open the Codex remote surface and start a new remote/local Codex thread on the paired desktop.
3. Send a simple test prompt, for example Post-(post-test) test.
4. Confirm the turn runs locally on the desktop.
5. On the desktop, verify the thread exists in local Codex state and is visible through Codex Desktop / Codex CLI local history.
6. Reopen or refresh the ChatGPT mobile Codex remote conversation list.
7. Observe that the mobile-started thread is not listed on mobile and cannot be resumed there.
8. Compare the backend current task list from the Desktop app cache or network logs; in my case wham/tasks/list?limit=20&task_filter=current returned an empty items list.

Additional comparison:

1. Start a separate thread directly from Codex Desktop.
2. Confirm that Desktop-started thread appears in Codex Desktop, CLI, and mobile.
3. Compare the local state/logs for that thread against the mobile-started missing thread.

What is the expected behavior?

Threads started from ChatGPT mobile and/or the Codex CLI should remain visible and resumable from ChatGPT mobile after creation, as long as the paired desktop/local app-server still has the thread and the same account is connected.

Additional information

Related but not exact prior issues I found before filing:

• #23321: stale iOS Remote Control host / 403 after hostname change
• #23317: mobile device list exposes Desktop-managed SSH remotes as Codex Desktop devices
• #12651: /wham/tasks/list 403 in VS Code/Windsurf/MCP auth path
• #20757 / #9224: mobile companion / remote control feature requests
• #16614: app-server custom-client thread visibility and source: vscode
• #14722: sync CLI and app-server sessions

This issue seems narrower than those: mobile can create the local remote thread, and local state persists it, but the backend/mobile task list appears not to index it for later mobile resume.