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

Open 💬 0 comments Opened Aug 10, 2026 by lextiz

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

Start a Codex Remote Voice session from the ChatGPT Android app against a Windows desktop host.
End or stop Voice.
Archive the Voice thread.
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:

thread archive state,
the Realtime Voice transport,
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

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

View original on GitHub ↗