Skip to content

Permission prompt interrupts active voice dictation and discards audio #21445

@achievevitality

Description

@achievevitality

Codex Feedback Report: Permission Prompt Interrupts Active Voice Dictation And Discards Audio

Status: draft
Created: 2026-05-06
Product area: Codex desktop app, in-app voice dictation, permission prompts / approvals
Severity: high user-impact data loss / workflow break
Submitted:
GitHub issue:

Subject

Codex should preserve active dictation when a permission prompt appears during recording.

Message

I am reporting a Codex desktop app voice-dictation failure mode that creates data-loss risk during normal interactive use.

On May 6, 2026 around 5:30pm PT, I started recording an audio message in a Codex window while that window was mid-turn. During my recording, Codex asked me for permission for something it was doing. When the permission request appeared, the in-progress voice recording was lost.

The lost audio was approximately the first 2-3 minutes of my message.

I am not certain whether this is a persistent issue or a new regression. I vaguely remember a similar permission interaction a few days ago, but I do not remember whether the prior recording was preserved. Please treat this report as a confirmed occurrence of the issue today, not as a fully characterized recurrence pattern.

Why This Matters

This means I cannot safely use Codex voice-to-text while Codex is actively working. If the app may ask for permissions mid-turn, then I risk losing whatever I am recording at that moment.

That breaks an important workflow: using voice input to steer, correct, or add context to an active Codex conversation.

For complex work, voice capture is often the most efficient way to communicate high-context instructions. Losing the original audio is not just an inconvenience; it can destroy a live thought capture that is difficult or impossible to recreate with the same detail.

Observed Behavior

  1. Codex was mid-turn in another window.
  2. I began recording a voice-to-text message in that window.
  3. While I was recording, Codex displayed a permission request.
  4. The in-progress recording was discarded/lost.
  5. Approximately 2-3 minutes of dictated material were lost.

Expected Behavior

Codex should not discard in-progress dictation because a permission prompt appears.

Safer behavior would be one of:

  1. Preserve the active recording through the permission prompt.
  2. Pause the recording while the permission prompt is active, then resume after the user responds.
  3. Stop and save the audio as a recoverable draft before showing the permission prompt.
  4. Prevent permission prompts from interrupting active dictation.
  5. Warn the user that dictation during active turns is unsafe if this cannot be supported yet.

Requested Product Changes

Please consider:

  • preserving active dictation state when permission prompts appear;
  • saving partial audio locally before any UI transition that interrupts recording;
  • making permission prompts non-destructive to active user input;
  • adding tests for voice recording + permission prompt interactions;
  • adding explicit UI warnings if voice dictation cannot safely coexist with active tool/permission workflows.

Related Issue

This is related to, but distinct from, my earlier Codex audio report:

https://github.com/openai/codex/issues/21408

That issue was about long dictation failing transcription and losing unrecoverable audio. This issue is about a permission prompt interrupting and discarding an active recording.

Desired Outcome

Voice input should be safe to use while Codex is working.

At minimum, Codex should never discard recorded audio because an approval or permission prompt appears mid-recording.

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingtool-callsIssues related to tool calling

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions