Android Remote only loads threads manually opened on Windows host; other threads stay loading

Summary

Codex Remote Control on Android can connect to a Windows Codex Desktop host and start work, but most existing threads remain stuck loading on mobile.

Only a thread that has been manually opened/refreshed in Codex Desktop becomes readable on Android. If another thread is selected on Android, it stays loading until that same thread is opened on the Windows desktop.

This appears to be a regression or remaining variant of #22762.

Environment

• Host: Windows
• Codex Desktop: 26.727.4816.0
• Mobile: ChatGPT Android app
• Remote Control enrollment succeeds
• Codex Desktop package status: Ok

Reproduction steps

1. Start Codex Desktop on Windows with Remote Control enabled.
2. Leave only thread A open on the desktop.
3. Connect from ChatGPT Android Remote Control.
4. Thread A can be opened on mobile.
5. Try to open an existing thread B on mobile.
6. Thread B remains stuck loading.
7. Remotely operate the Windows PC and manually open thread B in Codex Desktop.
8. Thread B immediately becomes readable on Android.
9. Start more work from mobile. To see the updated result, manually open/refresh the target thread again on the desktop.

Expected behavior

Android Remote Control should list, read, resume, and continuously update existing host threads without requiring the desktop UI to manually open each thread.

Actual behavior

• Work submitted from Android can execute on the host.
• Progress and results do not hydrate on Android.
• Re-pairing Remote Control temporarily refreshed all threads once, but the problem returned.
• Restarting the PC, reinstalling Codex Desktop, and re-enrolling Remote Control did not provide a durable fix.
• The currently opened desktop thread remains accessible while other persisted threads remain stuck loading.

Host-side evidence

After reproducing:

• Local thread/list succeeds on the Windows host.
• thread/read / thread/resume succeeds for the thread currently opened on the desktop.
• For threads that remain stuck loading on Android, no corresponding thread/read request reaches the Windows host logs.
• Remote Control status/read and enable complete successfully.

This suggests the Android client or Remote relay is not issuing/forwarding the read request for persisted threads, rather than the Windows host failing to serve it.

Local state checks

A separate corrupt local process-notification registry was found and repaired. After repair, its JSON/NUL errors disappeared, but the Remote thread-loading problem remained unchanged.

The main local state database also passed both:

• PRAGMA quick_check → ok
• PRAGMA integrity_check → ok

The database contains 682 threads and one valid Remote Control enrollment with a non-empty client name. This does not match the malformed threads-table case in #23247 or the empty client-name variant in #24024.

Related reports

• #22762 — Android Remote Control does not load host thread history; no thread/list requests observed
• #22773 — stale/offline/mobile hydration failures
• #24024 — Remote session can become stale and temporarily recover after re-enrollment
• #24179 — Remote Control state can diverge from an active desktop connection

Additional information

The behavior is highly consistent and makes Remote Control unusable for supervising work away from the PC. The only reliable workaround is to separately remote-control the Windows desktop and manually open each target thread, which defeats the purpose of mobile Remote Control.

Detailed logs are available, but were not attached publicly because they contain thread identifiers and environment metadata. A redacted extract can be provided if requested.