Android Codex shows stale local project threads despite connected desktop until remote-control enrollment reset
Summary
ChatGPT Android Codex can show a green/connected local desktop target while rendering a stale project thread list. In this case, clearing Android app cache/data, uninstalling/reinstalling ChatGPT, logging back in, and reconnecting did not fix it. Resetting the desktop Codex remote-control enrollment forced a new desktop remote-control environment, after which Android showed the current project threads again.
Environment
- Codex Desktop: 26.519.41501
- Bundled codex-cli/app-server: 0.133.0-alpha.1
- ChatGPT Android: 1.2026.125
- Android: Android 16, Samsung device
- Feature area: ChatGPT mobile app > Codex > local desktop remote-control connection
Symptoms
- Android showed the local desktop as connected.
- A project page under that desktop showed only an old thread from the date the remote-control enrollment was originally created.
- Newer threads for the same project/cwd did not appear.
- "Load older threads" did not change the list.
- Clearing Android cache/data and fully reinstalling ChatGPT did not change the stale list.
- The phone briefly attempted to load a newer/current thread, then it disappeared before loading finished.
Local Evidence
- Desktop SQLite state contained all expected current project threads.
- The missing threads were unarchived user threads with the same cwd as the visible old thread.
- Direct local app-server
thread/listfor that cwd returned all expected current threads in the correct updated order. - Desktop logs showed successful
thread/listresponses. - Android logcat did not show a relevant crash.
- Before the workaround, the desktop
remote_control_enrollmentsrow still had the original older remote-control server/environment identity.
Workaround That Fixed It
- Backed up:
~/.codex/state_5.sqlite~/.codex/.codex-global-state.json
- Cleared only local remote-control identity/enrollment state:
- SQLite table:
remote_control_enrollments - global-state keys:
electron-local-remote-control-environment-idelectron-local-remote-control-installation-idelectron-remote-control-client-enrollmentscodex-mobile-has-connected-deviceadded-remote-control-env-ids
- Restarted Codex Desktop.
- Desktop registered a new remote-control environment/server.
- Android briefly showed two desktop entries with the same display name, then reconciled to one.
- Android Codex then showed the current project threads correctly.
Expected Behavior
If the Android app shows a local desktop as connected, project thread lists should reflect the current desktop app-server/thread database, or the UI should detect and recover from a stale remote-control environment.
Actual Behavior
The Android app stayed connected to a valid but stale remote-control environment/index. The connection indicator was green, but the project thread list was stuck on old data until the desktop remote-control identity was reset.
Hypothesis
There may be a backend/mobile reconciliation bug where an older remote-control environment remains valid and connected but serves stale project/thread indexing. Reinstalling the Android app reconnects to the same stale remote-control identity, so phone-side cache clearing does not help.
Privacy Note
I have omitted hostnames, usernames, account IDs, environment/server IDs, project names, local paths, screenshots, thread IDs, and prompt contents. I can provide more detailed logs privately if needed.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗