Codex Desktop mislabels automatic WebRTC failure cleanup as user-ended realtime session

Start by tracing realtime session stop and transcript finalization in codex-rs/core/src/realtime_conversation.rs and the related types in codex-rs/app-server-protocol/src/protocol/v2/realtime.rs. Verify where the WebRTC failure reason is lost or ignored. Done means automatic failures are reported as connection_lost or webrtc_failed, while the transcript tail is flushed once without user-ended wording.

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 (build 5828)
• 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:

1. 10:29:31.957 — a realtime voice session started.
2. 10:38:29.636 — the desktop renderer logged Realtime voice WebRTC connection failed.
3. 10:38:29.640 — four milliseconds later, the same renderer called thread/realtime/stop.
4. The later transcript-tail handoff reported that the user had ended the session.
5. 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: RealtimeConversationClose has no client_user_message_id.
• An earlier identical WebRTC failure was followed by source=transcript_tail_flush with “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.