Voice task becomes trapped when a plugin approval dialog appears

Summary

In a voice-first Codex desktop session, the task became trapped when a plugin-install approval was required. The voice frontend repeatedly said it was checking, but did not announce the pending approval, identify the required control, ask for the missing decision, or return with a clear blocker. Repeated voice prompts did not recover the task, and the app had to be restarted.

This is accessibility-critical for blind users because the approval UI is not independently visible.

Reproduction

1. Start a realtime voice conversation in the Codex desktop app on macOS.
2. Begin a workflow that eventually requests installation of a plugin.
3. Verbally approve the installation.
4. Allow the task to enter the plugin approval state.

Observed behavior

• The affected task remained active with waitingOnApproval.
• Voice repeatedly used progress language such as “I’m checking.”
• Voice did not announce that an approval dialog or pending approval existed.
• Voice did not identify the relevant buttons, current focus, or exact action required.
• Voice did not time out with a concrete blocker.
• Repeated voice prompts could wake the assistant, but it remained nonproductive.
• The user ultimately restarted the app.

The issue occurred immediately after the user verbally authorized installation of the Runway plugin during a talking-avatar workflow. Work completed before that point was preserved; the approval-state turn remained unfinished.

Expected accessible behavior

When a task is waiting for approval during realtime voice:

1. Immediately announce that an approval is pending.
2. State what is being approved and why.
3. Announce every relevant button and the currently focused control.
4. Tell the user the exact keyboard or spoken action required.
5. If the UI cannot be controlled or verified, stop repeating progress phrases and state the blocker plainly.
6. Re-announce the pending approval when the user asks for status.
7. Provide a deterministic cancellation or recovery path that does not require restarting the app.

Accessibility impact

The reporter is a blind, voice-first developer working on computer interfaces for blind users. For a sighted user, the pending approval may be visually obvious; for a blind user relying on spoken state, the task appears to be working indefinitely. This makes approval-gated workflows unreliable and can strand the entire voice session.

The reporter is willing to provide systematic, real-world blind-accessibility testing and reproducible bug reports if OpenAI is interested. Please contact the reporter through this GitHub issue rather than requiring an email address to be posted publicly.

Privacy

The underlying workflow used a private face-and-voice recording, but that recording is unrelated to the bug and is not attached. No passwords, credentials, private media, or unrelated personal content are included in this report.

Start by reproducing the approval flow in a realtime voice conversation on macOS, then trace the handling of the reported waitingOnApproval state in the Codex desktop app. Check how pending approval, focus, available actions, status requests, timeout, cancellation, and recovery are exposed to voice. Done means the task announces the blocker and required action, re-announces it on request, and recovers without an app restart.