Codex Desktop mislabels automatic WebRTC failure cleanup as user-ended realtime session
Summary
When a Codex Desktop realtime voice WebRTC connection fails, the client automatically stops the session, but the backend/transcript-tail handoff reports that the user ended it.
Environment
- Codex Desktop
26.721.31836(build5828) - Bundled app-server
0.146.0-alpha.3.1 - macOS
27.0(26A5388g), Apple silicon
Reproduction / observed timeline
All times are EDT on 2026-07-24:
10:29:31.957— a realtime voice session started.10:38:29.636— the desktop renderer loggedRealtime voice WebRTC connection failed.10:38:29.640— four milliseconds later, the same renderer calledthread/realtime/stop.- The later transcript-tail handoff reported that the user had ended the session.
10:40:46.759— the still-running app started another realtime voice session successfully.
Local corroboration (home-relative paths only):
~/Library/Logs/com.openai.codex/2026/07/24/codex-desktop-…log, lines 14085–14101: session start and ID; line 15313: WebRTC failure; line 15314: automatic stop; lines 15608–15621: successful restart in the same app.~/.codex/logs_2.sqlite:RealtimeConversationClosehas noclient_user_message_id.- An earlier identical WebRTC failure was followed by
source=transcript_tail_flushwith “The user just ended their realtime session.”
The affected app did not restart or crash; there was no sleep/wake event or session-limit indication. The exact ICE/network subcause was not logged.
Expected behavior
An automatic WebRTC failure cleanup should be reported as connection_lost / webrtc_failed, not as user intent. The transcript tail should still be flushed once, and the UI should offer or attempt reconnection.
Likely cause
The client distinguishes the WebRTC failure path internally, but that end reason is lost or ignored by the server-facing stop/finalization path. Tail flushing is generic session cleanup, so it must not imply a user-requested stop.
Relevant code:
- https://github.com/openai/codex/blob/main/codex-rs/core/src/realtime_conversation.rs
- https://github.com/openai/codex/blob/main/codex-rs/app-server-protocol/src/protocol/v2/realtime.rs
Suggested fix
Carry a required end reason through stop and transcript finalization, e.g. user_requested, webrtc_failed, inactivity, app_unmounted, and server_closed.
For webrtc_failed, preserve the transcript tail but use neutral connection_lost wording. Record the WebRTC/ICE state and end reason without transcript content, and add a bounded reconnect grace period where feasible.
1 Comment
Analysis (OSS verification)
Confirmed this is partly fixable in
openai/codex(app-server/core), with a required Desktop call-site change.What I verified
thread/realtime/stopparams are only{ threadId }— no end reason (ThreadRealtimeStopParamsinapp-server-protocol/.../realtime.rs).Op::RealtimeConversationClose, which ends asRealtimeConversationEnd::Requested.REALTIME_SESSION_ENDED_HANDOFF_INSTRUCTIONincore/src/realtime_conversation.rs), including forsource=transcript_tail_flush.requested/transport_closed/error, but that distinction is not carried into the handoff wording, and Desktop auto-stop currently looks like a user request.Suggested direction
thread/realtime/stop(experimental), g.user_requested,webrtc_failed,transport_closed,error,server_closed.connection_lostwording for non-user reasons.webrtc_failed(or equivalent) on automatic WebRTC cleanup instead of a bare stop.Happy to refine once a maintainer confirms the intended reason enum / wording.