Codex Desktop loses pending dictation after ASR failure and window/thread switch

Summary

A long Codex Desktop dictation can be permanently lost when transcription fails and the user switches away from the thread/window. The retry UI disappears after returning to the thread, and the recorded audio appears not to be persisted anywhere recoverable.

This is a severe UX/data-loss issue for voice-heavy workflows. In my case, I dictated roughly 30 minutes of content. The ASR request failed, and after switching to another window and back there was no retry button and no recoverable recording.

Environment

• App: Codex Desktop
• Platform: macOS
• CLI/app runtime observed in session metadata: 0.140.0-alpha.19
• Date/time observed locally: 2026-06-18 around 01:36-01:54 CST

What happened

1. I dictated a long message in Codex Desktop, roughly 30 minutes.
2. Transcription failed with dictation failed / Error in ASR API.
3. Initially there was a retry affordance.
4. I switched to another Codex window/thread and later returned.
5. The retry button was gone.
6. The dictated audio/content was not present in the thread and could not be recovered.

Evidence from local logs

Repeated failures occurred in the Codex Desktop log. The log timestamps are UTC; local time was CST (UTC+08:00).

2026-06-17T17:36:29.750Z error [electron-message-handler] [Composer] dictation failed errorMessage="{\"detail\":\"Error in ASR API\"}"
2026-06-17T17:41:52.453Z error [electron-message-handler] [Composer] dictation failed errorMessage="{\"detail\":\"Error in ASR API\"}"
2026-06-17T17:45:01.503Z error [electron-message-handler] [Composer] dictation failed errorMessage="{\"detail\":\"Error in ASR API\"}"
2026-06-17T17:46:26.160Z error [electron-message-handler] [Composer] dictation failed errorMessage="{\"detail\":\"Error in ASR API\"}"
2026-06-17T17:47:42.010Z error [electron-message-handler] [Composer] dictation failed errorMessage="{\"detail\":\"Error in ASR API\"}"
2026-06-17T17:48:47.639Z error [electron-message-handler] [Composer] dictation failed errorMessage="{\"detail\":\"Error in ASR API\"}"
2026-06-17T17:51:54.776Z error [electron-message-handler] [Composer] dictation failed errorMessage="{\"detail\":\"Error in ASR API\"}"
2026-06-17T17:54:40.446Z error [electron-message-handler] [Composer] dictation failed errorMessage="{\"detail\":\"Error in ASR API\"}"

I also scanned the relevant local time window (2026-06-18 01:36-01:56 CST) under the Codex app support directory and the system temp directory. Only screen recording frames, browser state DBs, GPU/Dawn cache, and network state files were modified. I did not find a recoverable dictation audio container/blob such as wav, m4a, webm, mp4, or caf for the failed attempts.

Expected behavior

Codex should not discard the original dictation audio or user content until either:

• transcription succeeds and the user sends/discards the text, or
• the user explicitly chooses to delete/discard the recording.

At minimum, after ASR failure:

• the retry affordance should survive thread/window switching, rerenders, and app navigation;
• the original audio should be persisted temporarily and recoverably;
• the user should be able to export or retry the audio;
• a long-running dictation should show a stronger warning before any state is lost.

Actual behavior

After ASR failure and switching away/back, the retry UI disappeared and the audio was not recoverable from the thread or local disk. This caused unrecoverable loss of roughly 30 minutes of dictated input.

Suggested fix

Persist pending dictation recordings to a temporary per-thread draft store before starting ASR, and keep a durable pending-dictation record with state like recorded, transcribing, transcription_failed, retrying, discarded, and sent.

The UI should rehydrate this record when returning to the thread and offer retry/export/discard. For long recordings, Codex should not rely only on an in-memory renderer Blob.