[app][Windows][26.727.6591.0] New voice chat races startup watchdog before Realtime begins

What version of the Codex App are you using?

• Codex Desktop: 26.727.6591.0
• Bundled Codex CLI: 0.146.0-alpha.9.2

What subscription do you have?

Not provided.

What platform is your computer?

• Windows x64
• Windows build 26200.8875

What issue are you seeing?

Starting a new Voice Chat from the global/avatar voice entry intermittently fails with:

Voice chat took too long to start

Retrying after the app has warmed up, or starting Voice Chat from an existing task, usually succeeds.

The failure occurs while Desktop is still creating the provisional task, before thread/realtime/start, WebRTC, ICE, or microphone initialization begins.

Steps to reproduce

1. Fully quit Codex Desktop.
2. Relaunch it.
3. During the cold-start period, select Start new voice chat from the global/avatar voice entry.
4. Observe that the overlay waits and may report Voice chat took too long to start.
5. Retry after the app is warm, or open an existing task first and start Voice Chat from its composer.
6. Observe that the warm/existing-task path usually succeeds.

Sanitized failing timeline

All timestamps are UTC.

08:21:06.920  provisional thread/start begins
08:21:15.628  "Voice chat took too long to start"
08:21:15.904  thread/start returns, durationMs=8984

The provisional thread/start response arrived only 276 ms after the client declared voice startup timed out.

No thread/realtime/start call was made during this attempt. Therefore, the failing critical path had not reached Realtime, WebRTC, ICE, or microphone-track setup.

A second cold-start failure showed the same race:

10:00:48.716  "Voice chat took too long to start"
10:00:49.329  thread/start returns, durationMs=5696

Here, thread/start completed 613 ms after the timeout.

The pending provisional task continued to materialize after the client had timed out, followed by:

Failed to discard provisional realtime voice thread
Inactive thread archive did not persist

This suggests the watchdog does not reliably cancel the pending task creation and can leave cleanup work behind.

Successful warm-start control

A successful new Voice Chat after the application was warm:

thread/start                    2274 ms
thread/realtime/start RPC          7 ms
realtime_session_started       +1344 ms
realtime_session_updated       +2626 ms

Total time from initiating thread/start until voice became available was approximately 6.3 seconds.

Starting Voice Chat from an existing task skips provisional thread/start and takes approximately 4 seconds.

Expected behavior

• A normal cold-start delay should not cause new Voice Chat to fail just before provisional task creation completes.
• Provisional task creation and Realtime/WebRTC startup should have separate, stage-specific time budgets.
• Nonessential task-start work should not consume the voice-critical timeout budget.
• If the watchdog fires, the pending thread/start should be cancelled or its eventual result should be cleaned up reliably.

Actual behavior

• One combined startup watchdog expires while thread/start is still pending.
• The response can arrive only a few hundred milliseconds too late.
• Realtime setup is never attempted in the primary failure.
• The provisional task can still materialize after timeout, and archive/discard cleanup can fail.
• Warm and existing-task paths work.

Contributing cold-start work observed

During reproduced cold starts, Desktop was also doing some combination of:

• SessionStart hooks;
• bundled plugin marketplace reconciliation/synchronization;
• Browser Use runtime initialization;
• multiple plugin-list requests;
• at incident time, preconnecting a configured SSH app-server even though Voice Chat used hostId=local.

The SSH connection was later removed. It was concurrent load, not a direct authentication dependency for voice.

One installed Vercel plugin has three synchronous SessionStart hooks. Its optional telemetry request can wait up to three seconds. With telemetry disabled, the hooks benchmarked at approximately 0.21 seconds. However, this plugin is not the sole cause: a cold-start voice timeout was also reproduced while the entire plugin was disabled.

A malformed local process index was also found to contain only NUL bytes and had generated repeated JSON parse errors. Quarantining it removed that background noise, but it was not the sole cause either.

Items ruled out

• Windows microphone permission was enabled.
• The default microphone was active and not muted.
• Windows audio services were healthy.
• Codex accessed the microphone during testing.
• The OpenAI Realtime WebSocket proxy handshake completed in approximately 1.1 seconds.
• STUN/UDP connectivity tests succeeded.
• The primary failure occurred before thread/realtime/start, so it was not caused by WebRTC or microphone initialization.
• Voice used hostId=local; SSH authentication was not a direct cause.

Suggested fixes

1. Do not use one short watchdog for provisional thread/start plus Realtime/WebRTC startup.
2. Give provisional task creation and Realtime startup separate budgets (for example, 30 seconds and 10–15 seconds).
3. Materialize and return the provisional task ID before awaiting nonessential SessionStart hooks.
4. Defer nonessential hooks, telemetry, plugin synchronization, and remote-host preconnection until after the Realtime session starts.
5. Expose a voice-specific origin to hooks so they can skip/defer noncritical work.
6. Cancel pending thread/start when the voice watchdog fires, or reliably reconcile and archive its eventual result.
7. Add explicit per-stage timing logs such as overlay_ready, thread_materialized, session_hooks_complete, realtime_session_created, webrtc_connected, and audio_track_ready.

Related issue

• openai/codex#35252 reported a similar user-visible timeout on an earlier Windows build, but that report reached thread/realtime/start and then received a null Realtime session ID.
• This report is distinct because the primary failure occurs earlier: thread/start misses the client watchdog by only 276 ms and Realtime is never called.

Current workaround

Wait 10–15 seconds after launching Codex, or open an existing task first and start Voice Chat from that task.

Privacy note

This report intentionally excludes usernames, task IDs, local project paths, conversation contents, raw logs, authentication material, and SSH details. Additional sanitized timing excerpts can be provided if needed.