Repository navigation
Codex Desktop mislabels automatic WebRTC failure cleanup as user-ended realtime session #35201
Description
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.
Activity
rohanpatel2002 commentedon Jul 24, 2026
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.
mmnm commentedon Sep 8, 2026
Additional observation on macOS, September 7, 2026, submitted at the request of the affected user.
Environment: macOS 26.6.2 (25G83). The nearby desktop renderer log reports release 26.901.51231; the app bundle version was not independently retrieved.
Observed sequence in local desktop logs:
Realtime voice WebRTC connection failedfor that session.thread/realtime/stopresponse with no application error code.This independently corroborates the misleading end-reason symptom described in this issue. It does NOT establish the underlying network/ICE cause or a two-hour session limit. This is one observed event, not a controlled reproduction. No assistant end-call action was issued in the affected conversation.
Expected: preserve the conversation, identify unexpected connection loss accurately, and offer a clear recovery/reconnect action instead of attributing the stop to user intent. If an intentional duration limit applies, explain it and provide a graceful continuation path.
Privacy: only sanitized diagnostic facts are included. No transcript, project content, account details, local paths, session/task identifiers, screenshots, credentials, or raw log files are attached.