[app][Windows ARM64] Natural display timeout converts live Voice control to Play state while Codex task continues

Summary

On a Microsoft Surface Pro (11th Edition) running Windows 11 Pro 10.0.26200, with the ARM64 Codex package OpenAI.Codex 26.727.6591.0, a natural display timeout changes the live Voice control into a small Play control after the display is woken.

The trigger is the normal display timeout. This is not Win+L, the power button, explicit Sleep, or closing the cover. The main Codex task continues normally while the display is off, so this does not appear to be system sleep.

Immediately after waking the display:

• the live Voice control is gone;
• a small Play button occupies the same control location; and
• speaking is unavailable.

Voice later returns after a delay.

Reproduction protocol

1. Start a Codex task that can continue while unattended.
2. Start Voice and speak continuously.
3. Leave the device untouched and allow the natural display timeout. Do not use Win+L, the power button, explicit Sleep, or cover close.
4. After the display turns off, verify after wake that the main Codex task continued normally.
5. Wake the display normally.
6. Observe that the live Voice control has become a small Play button in the same location, and that speaking is unavailable.
7. Record the delay until Voice returns.

Expected behavior

Voice should remain live across a display-only timeout while the Codex task continues, or the app should clearly indicate if Windows display-off Voice continuity is unsupported. After wake, the live Voice control and speaking should recover immediately or provide a clear reconnect state.

Actual behavior

The separate Voice/realtime overlay appears to transition out of its live state when the display turns off and reconnect after wake. This is an inference from the observed UI sequence, not an established internal mechanism.

Is Windows display-off Voice continuity unsupported, or is this a bug in the display-off/wake handling?

Environment

• Device: Microsoft Surface Pro, 11th Edition
• OS: Windows 11 Pro 10.0.26200
• Codex package: OpenAI.Codex 26.727.6591.0 ARM64

Diagnostic guidance

I am not including private logs, filesystem paths, thread/session IDs, screenshots, or other diagnostics. Which sanitized log categories would be useful for a follow-up? In particular, would maintainers want events related to thread/realtime/start and stop, realtime_session, avatarOverlay, AppServerConnection, maybe_resume, websocket, or audio/playback state?