Codex Desktop voice transcription failures can discard unrecoverable audio
What happened?
In Codex Desktop, voice input / speech-to-text can fail or produce an obviously incomplete transcription. When that happens, the original recorded audio appears to be unavailable: it is not attached to the conversation, not referenced in the session JSONL, and not discoverable in the local Codex cache or transcription history.
This makes voice input risky for longer or important recordings, because a transcription failure can mean the user loses both the transcription and the original audio.
Why this matters
For use cases like interviews, meetings, notes, or spoken bug reports, users may rely on Codex voice input as the capture mechanism. If STT fails and the raw audio is discarded, there is no recovery path.
Observed behavior
- The session JSONL only recorded the user text event and did not contain an audio attachment or local audio path.
~/.codex/transcription-history.jsonlcontained only the transcription text, not the source audio file path.- Searching common local locations such as the workspace,
~/.codex, Codex application support/cache directories,/tmp, and/var/foldersdid not reveal a corresponding audio file. - In one case the resulting transcription was only a tiny fragment (for example,
嗯?) even though the intended recording was much longer.
Expected behavior
Codex should provide a recovery path when voice transcription fails or produces incomplete output. Possible fixes:
- Keep the original audio locally until the transcription succeeds and the user sends/accepts it.
- If transcription fails, expose a retry option using the original audio.
- Attach or link the temporary audio file in the session record until the turn is complete.
- Make the retention behavior explicit in the UI, especially for longer recordings.
- Consider saving failed voice captures to a recoverable local folder, with a clear privacy/retention policy.
Environment
- App: Codex Desktop
- Platform: macOS
- CLI version observed in session metadata:
0.133.0-alpha.1 - Source: VS Code / Codex Desktop session
Additional context
This issue is about reliability and data recovery, not transcription accuracy alone. Even if transcription can fail occasionally, the user should not lose the original audio without a way to retry or recover it.
3 Comments
Audio Recovery Fix — Solution Submission
1|# Codex #24535 — Voice Transcription Failures Discard Unrecoverable Audio
2|
3|## Problem
4|
5|When Codex Desktop voice input / speech-to-text fails or produces incomplete transcription, the original recorded audio is unavailable — not attached to the conversation, not in session JSONL, and not discoverable in local cache. Users lose both the transcription and the original audio.
6|
7|## Root Cause
8|
9|The voice recording pipeline discards the raw audio file after sending it for transcription, without keeping a local copy for recovery. If transcription fails or produces incomplete output, there is no way to retry or recover the audio.
10|
11|## Fix
12|
13|### 1. Retain audio locally until transcription succeeds
14|
15|```typescript
16|// In the voice recording pipeline:
17|
18|interface VoiceRecording {
19| audioPath: string;
20| transcription: string | null;
21| status: 'recording' | 'transcribing' | 'completed' | 'failed';
22| createdAt: number;
23| retainedUntil: number; // NEW: Retention deadline
24|}
25|
26|class VoiceRecorder {
27| private recordings: Map<string, VoiceRecording> = new Map();
28| private readonly RETENTION_MS = 24 60 60 * 1000; // 24 hours
29|
30| async recordAndTranscribe(): Promise<VoiceRecording> {
31| const recordingId = crypto.randomUUID();
32| const audioPath = await this.startRecording();
33|
34| const recording: VoiceRecording = {
35| audioPath,
36| transcription: null,
37| status: 'recording',
38| createdAt: Date.now(),
39| retainedUntil: Date.now() + this.RETENTION_MS,
40| };
41|
42| this.recordings.set(recordingId, recording);
43|
44| try {
45| recording.status = 'transcribing';
46| const transcription = await this.transcribeAudio(audioPath);
47| recording.transcription = transcription;
48| recording.status = 'completed';
49|
50| // Only delete audio after successful transcription and user acceptance
51|
I am experiencing the same issue today (2026-08-12) in Codex Desktop on macOS.
Several voice dictation attempts failed after I had spoken for a long time. The app either produced no transcription at all, or displayed the red warning “Unable to transcribe audio”. In these cases, the spoken content was lost and there was no apparent way to retry or recover the audio.
This is especially damaging for long, detailed instructions. Please consider retaining the recorded audio locally until transcription succeeds and the user confirms it, and provide a Retry/Recover option when transcription fails. The UI should also make the failure reason clearer than the generic red warning.
Please treat failed recordings as recoverable data rather than silently discarding them.
Additional report from the same user on 2026-08-12:
There is also an intermittent UI/input failure: when I press the voice-to-text recording button, nothing happens or the recording/transcription does not start. I often have to press the button a second time before it works.
Voice transcription also feels significantly slower today. Even very short spoken messages can take an unusually long time to become text. The combination of missed first clicks, repeated clicks, long transcription delays, and complete failures makes voice input frustrating and unreliable for normal use.
Please investigate both the button/start-recording state transition and the transcription latency. The UI should provide clear immediate feedback that recording has started and should not require users to click twice.