[app][Windows][26.721.4979.0] New realtime voice chat times out with unmaterialized provisional thread

Summary

On the Windows desktop app, starting a new realtime voice chat repeatedly times out while the provisional voice thread is still unmaterialized.

The app-server accepts thread/realtime/start, but Desktop receives realtime_session_started with realtimeSessionId=null. At the same time, Desktop attempts to hydrate the empty provisional thread with includeTurns, receives -32600 because the thread has no first user message, times out the voice overlay, and then fails to discard/archive the provisional thread.

Environment

• App package: OpenAI.Codex 26.721.4979.0 (Windows Store)
• Bundled app-server: 0.146.0-alpha.3.1
• Platform: Windows 11 Pro 23H2, x64, build 22631.6199
• Authentication: ChatGPT
• Subscription: Enterprise; realtime voice is enabled and worked earlier the same day

Steps to reproduce

1. Fully exit and reopen the Windows desktop app.
2. Open a new, empty task.
3. Select Start new voice chat before sending a message.
4. Wait for the voice overlay to start.

Actual behavior

The overlay waits and then reports:

Voice chat took too long to start

Multiple attempts produce the same sequence. A representative sanitized timeline (UTC) is:

21:27:42.742  thread/realtime/start accepted
21:27:43.223  thread/read -> -32600:
                  "thread <id> is not materialized yet;
                   includeTurns is unavailable before first user message"
21:27:44.950  realtime_session_started realtimeSessionId=null
21:27:45.258  Voice chat took too long to start
21:27:45.513  Inactive thread archive did not persist
21:27:45.514  Failed to discard provisional realtime voice thread

A subsequent attempt again emitted realtime_session_started with a null session ID.

Expected behavior

The provisional voice task should materialize without an invalid includeTurns read, receive a valid rtc_... session ID, and open the realtime voice conversation. If startup fails, the provisional task should still be cleaned up successfully.

Regression evidence

Earlier the same day, package 26.721.3996.0 successfully emitted:

realtime_session_updated realtimeSessionId=rtc_...

and realtime voice worked. The startup failures began after moving to package 26.721.4979.0.

What was ruled out

• Windows microphone access is allowed globally and for OpenAI.Codex.
• Windows recorded Codex microphone use during the failed attempt.
• Audiosrv and AudioEndpointBuilder were running.
• Voice discovery (thread/realtime/listVoices) returned successfully.
• TCP 443 connectivity to chatgpt.com and api.openai.com succeeded.
• The failure sequence occurs before a valid realtime session ID or a WebRTC connection-failure event.

Relevant launch context

The captured reproduction used a separate launcher with this Chromium transport preference:

--force-webrtc-ip-handling-policy=disable_non_proxied_udp

No other debug/logging flags remained. The same preference successfully started realtime voice on the earlier package. The current failure appears to happen in provisional-thread/session startup before WebRTC transport establishment, but this non-default launch argument is included here for completeness.

Related issues

• #35201 covers WebRTC failure cleanup after a session has started.
• #33120 covers archive failures for unmaterialized tasks.
• #35103 covers voice-thread lifecycle behavior after inactivity timeout.

I did not find an existing issue combining Windows realtime-voice startup timeout, an unmaterialized provisional task, a null realtime session ID, and failed provisional-task cleanup.

13:59:05  realtime conversation start submitted
13:59:07  POST realtime/calls -> 201 Created
13:59:07  valid rtc_... Location received
13:59:07  realtime conversation started
13:59:14  Desktop sends RealtimeConversationClose and Shutdown
13:59:14  thread/archive tears down the listener with an active turn