[Android][Remote Voice][Windows] Archived Voice thread remains active on mobile

Summary

After ending and archiving a Codex Realtime Voice thread from ChatGPT Remote on Android, the archived Voice session remained shown as active on the mobile device and could not be stopped.

On the Windows host, no active rollout existed for the retained recent-Voice thread ID, while desktop global state still contained a realtime-voice-most-recent-thread pointer referencing an archived thread. Restarting the desktop host and removing only that stale pointer cleared the host-side stale state.

Environment

• Host: Windows x64, build 26200
• Codex Desktop: 26.803.5235.0
• Bundled Codex CLI: 0.147.0-alpha.6.5
• Client: ChatGPT Android app using Codex Remote Voice
• Observed: 2026-08-10

Steps to reproduce

1. Start a Codex Remote Voice session from the ChatGPT Android app against a Windows desktop host.
2. End or stop Voice.
3. Archive the Voice thread.
4. Observe that the thread is archived, but the mobile client still shows Voice as active and the stop control does not end it.

Expected behavior

Ending or archiving the Voice thread should terminate any associated Realtime transport, reconcile the recent-Voice pointer, and make the mobile client leave its active state. Repeated stop/archive requests should be safe and idempotent.

Actual behavior

The persistence/archive state and Voice transport/client state diverge:

• The Voice thread is archived.
• Mobile continues to show the Voice session as active and cannot stop it.
• The desktop host can retain a recent-Voice pointer to an archived thread even though there is no active rollout for that ID.
• Recovery required restarting the desktop host and removing the stale recent-Voice pointer.

Sanitized runtime evidence

voice_pointer=<archived-thread-id>
active_rollout_count=0
archived_rollout_count=1

recovery:
  desktop_host_restarted=true
  recent_voice_pointer_removed=true

post_check:
  voice_pointer_present=false
  state_database_quick_check=ok
  state_database_foreign_key_errors=[]

The archived chat was preserved; no conversation was deleted. Raw thread IDs, local paths, transcript content, account identifiers, and raw state files are intentionally omitted.

Host-side recovery was verified. The mobile UI after recovery was not independently captured, so the likely lifecycle race below is an inference rather than a confirmed root cause.

Suspected lifecycle gap

This appears to be a reconciliation problem between three independently persisted states:

1. thread archive state,
2. the Realtime Voice transport,
3. the mobile client's active-session state / desktop recent-Voice pointer.

Archiving is documented as moving the persisted thread log, but it apparently does not always close or invalidate the Voice transport and pointer atomically. See the App Server thread lifecycle documentation.

Related evidence

• #35629 — stale recent-Voice pointer repeatedly resumes an obsolete thread
• #36587 — Windows Voice startup cleanup/archive race
• #36761 — mobile Realtime Voice reopens/reuses the previous thread

This report is distinct: the user-visible failure is an already archived Voice thread remaining active and unstoppable on Android.

Start with the App Server thread lifecycle documentation and compare related reports #35629, #36587, and #36761; then reproduce the Android-to-Windows archive flow while tracing the archived thread, Realtime transport, and recent-Voice pointer. Done means archiving or stopping leaves no active mobile session or stale pointer, and repeated requests are idempotent.