Codex Desktop dictation accepts long recordings it cannot transcribe, then loses unrecoverable audio

Summary

Codex Desktop currently lets a user record a long in-app voice dictation that appears to exceed what the ASR/transcription flow can reliably process. When transcription fails, the raw audio is not exposed to the user in any recoverable form.

This creates a high-impact data-loss failure mode: Codex accepts the user’s spoken work, fails after the fact, shows a Retry state for a while, and can then lose the only copy of the original audio.

What happened

On May 5, 2026, I recorded a long voice-to-text capture inside the Codex desktop app. The recording was approximately 20-30 minutes and contained important, difficult-to-reconstruct business/system-design material.

Codex accepted the recording, attempted transcription, and failed with:

{"detail":"Error in ASR API"}

After the failure, the UI showed a Retry button instead of the microphone button, which strongly suggested that Codex still believed there was an audio payload available to retry. Repeated retries failed. Later, the Retry button disappeared, and the original audio was no longer recoverable.

A fresh short dictation in another Codex window worked, so this appeared to be payload-specific rather than a total ASR outage.

User impact

• A long, high-value original dictation was lost.
• The material was not easily reproducible because it was a live conceptual capture.
• The Retry state created false hope that the audio still existed somewhere.
• Recovery required substantial time and local diagnostic effort.
• I can no longer trust Codex in-app dictation for long or important captures.

This matters because Codex is often used for deep project work where voice capture is the most natural way to transfer complex context. This failure mode can cause real loss of thought-work, not just inconvenience.

Local recovery observations

During recovery, I inspected the local Codex/Electron process state and filesystem activity. Relevant observations:

• Main Codex process PID at the time: 73650
• Renderer PID at the time: 73668
• App-server PID at the time: 73661
• The renderer held fd 12 open at 4,415,253 bytes in a temporary .com.openai.codex.* file.
• lsof could see the fd, but the file was not recoverable through normal user-accessible paths.
• lldb attach was denied by macOS/hardened runtime, even with sudo.
• fs_usage monitoring during retries did not produce useful recoverable file events.
• ~/.codex/transcription-history.jsonl contained successful transcriptions only, not the failed one.

These observations suggest the recording may have exceeded an internal duration, size, payload, or timeout limit, or the retained Retry payload may have been incomplete/corrupt.

Expected behavior

Codex should never allow a user to record more audio than the app can safely process or preserve.

At minimum, Codex should behave more like ChatGPT voice capture, where recording is cut off after a defined safe limit rather than allowing a user to record indefinitely and then failing after the fact.

Requested product changes

Please consider adding safeguards such as:

1. Hard recording limit: if Codex dictation cannot reliably process recordings beyond a certain duration or size, stop recording before that limit and explain why.
2. Visible duration/countdown indicator while recording.
3. Preflight warning before users exceed a safe transcription length.
4. Preservation of failed audio, with options such as Download audio, Save audio locally, Retry transcription, or Send failed audio to support.
5. Do not remove Retry without preserving the payload or clearly telling the user what happened.
6. Include failed attempts in transcription history, with timestamp, duration, file size if known, error message, and whether audio was retained.
7. Replace {"detail":"Error in ASR API"} with a user-actionable error that distinguishes length, size, timeout, network/server, or corrupt/unsupported audio failures.

Desired outcome

The minimum acceptable behavior is a hard cutoff before Codex accepts an audio payload it cannot safely process. The better behavior is a resilient long-capture workflow with chunking plus local recovery of failed audio.