codex - 💡(How to fix) Fix Voice input can silently lose long dictated message with no recoverable draft/audio [1 comments, 2 participants]

What version of the Codex App are you using (From “About Codex” dialog)?

26.415.20818 (build 1727)

What subscription do you have?

Plus / Credits

What platform is your computer?

Darwin 22.6.0 arm64 arm

What issue are you seeing?

Long voice input can be silently lost in the Codex desktop app with no recoverable draft, transcript, audio file, or visible error.

I dictated a long technical task for approximately 30 minutes using voice input. After finishing, no text appeared in the chat composer and no message was sent. The entire dictated task was lost.

There was no visible error message, no failed-transcription state, and no recovery prompt.

This is a data-loss issue: the user can spend a long time dictating, reasonably assume the app is recording/transcribing, and then receive no output and no recovery path.

What steps can reproduce the bug?

I do not have a deterministic minimal repro yet, but this is what happened:

1. Open the Codex desktop app on macOS.
2. Use voice input to dictate a long technical task.
3. Continue dictating for a long period, approximately 30 minutes.
4. Finish dictation.
5. Observe that no transcript appears in the chat composer and no message is sent.
6. Try to recover the content from local app/system storage.

Observed result:

• The dictated content was lost.
• No error message was shown.
• No recoverable draft/transcript/audio artifact was found.

Local recovery check performed after the incident:

• ~/Library/Application Support/Codex
• ~/Library/Application Support/Codex/blob_storage
• ~/Library/Application Support/Codex/Cache/Cache_Data
• ~/Library/Application Support/Codex/Local Storage
• ~/Library/Application Support/Codex/Session Storage
• $TMPDIR
• /tmp
• ~/Library/Caches
• ~/Library/Containers/com.apple.VoiceMemos
• ~/Library/Group Containers
• recent audio files via Spotlight

No recent recoverable .m4a, .wav, .webm, .caf, .opus, .aac, .flac, draft transcript, or media/audio cache file was found.

Platform: Darwin 22.6.0 arm64 arm

Codex app: 26.415.20818 (build 1727)

Session id: 019d622a-207c-7ca1-b0f1-dbcaab6dd749

I do not have the session id available from the UI. If there is a way to retrieve it locally, please document it or expose it in the app/report dialog.

What is the expected behavior?

Voice input should not be silently discarded.

Expected behavior:

• While recording/dictating, the app should continuously persist either temporary audio chunks, partial transcript drafts, or both.
• If transcription fails, the app should show a clear error state.
• If the app loses connection, crashes, refreshes, or transcription fails, the user should be able to recover the unsent voice input.
• Long dictation should not depend on one final successful transcription step with no intermediate persistence.
• The app should warn before discarding unsent voice input.

Additional information

Suggested improvements:

1. Persist temporary audio chunks locally while recording.
2. Persist partial transcript drafts continuously.
3. Keep failed transcription artifacts long enough for recovery.
4. Add a “recover unsent voice input” flow after transcription failure, app restart, or failed send.
5. Show explicit recording/transcription status for long voice input.
6. Add a hard warning or autosave behavior for long voice input sessions.
7. Expose session id and diagnostic metadata in the UI so users can include it in bug reports.

Impact: This caused the loss of approximately 30 minutes of technical planning and task description. For users who rely on dictation for long, complex instructions, this is severe data loss rather than a minor UX issue.