[app][Windows][Voice] Workstation lock terminates active realtime Voice and can mislabel it inactive

Summary

On Windows, activating the workstation lock screen terminates or disables an active ChatGPT Voice/GPT-Live conversation in Codex Desktop. This has reproduced repeatedly even when the user was actively speaking immediately before the lock. After unlock, the Voice session may be ended or labelled inactive.

The underlying Codex task may continue running, suggesting that the failure is specific to the realtime Voice/media lifecycle rather than the whole application being suspended.

Environment

• Windows 11, x64
• Codex Desktop package: OpenAI.Codex 26.727.6591.0 x64
• Desktop executable: ChatGPT.exe
• Lock trigger: Windows lock screen; reproduced repeatedly
• Authentication: ChatGPT

Steps to reproduce

1. Open a new Voice chat in Codex Desktop.
2. Confirm that two-way audio is working.
3. Continue speaking so that the conversation is demonstrably active.
4. Allow the Windows lock screen to activate.
5. Continue speaking briefly while the workstation is locked.
6. Unlock the workstation.
7. Inspect the Voice control and conversation state.

A useful secondary comparison is to test automatic locking and Win+L separately.

Actual behaviour

Voice stops accepting speech or the realtime session ends. The conversation may be labelled inactive even though the user was actively speaking immediately before the lock. The underlying Codex task may continue running.

Expected behaviour

An active Voice conversation should remain connected across workstation lock, as an active Teams or Zoom call can, or Codex should explicitly document that locked-workstation Voice is unsupported.

If Windows, audio capture, or the network forces the connection to end, the UI and transcript should report a specific reason such as workstation_locked, audio_capture_lost, or webrtc_failed, rather than inactivity or user intent. The app should attempt or offer reconnection after unlock.

Teams/Zoom comparison

Teams and Zoom can maintain an active call across the same workstation-lock transition. This does not assume they share Codex's architecture; it demonstrates that continued realtime audio while locked is supported by Windows when an application manages its media, session, power, and network lifecycle accordingly.

Related issues

• #36618 — Windows display timeout removes live Voice while the Codex task continues
• #35103 — Voice thread disappears after inactivity timeout
• #35201 — automatic WebRTC failure cleanup is mislabelled as user-ended

#36618 is particularly close: it uses the same Codex package version and reports that display timeout removes Voice while the main task continues. It explicitly excludes Win+L, however, so this lock-screen reproduction is distinct.

Diagnostic guidance requested

Which sanitized desktop log categories would be most useful during the next reproduction? In particular:

• workstation lock/unlock and display/power transitions
• audio-capture state and speech/VAD activity timestamps
• WebRTC/ICE connection state
• thread/realtime/start and stop events
• realtime close reason
• Voice overlay lifecycle and reconnection events

It would also be useful for the app to distinguish lock-only, display-off, and Modern Standby transitions in its diagnostics.