[Codex Desktop][macOS][Voice] Delivered turns remain in failed Retry queue

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

Not captured for this reproduction.

What subscription do you have?

Not included in this sanitized report.

What platform is your computer?

macOS

What issue are you seeing?

Voice turns were successfully delivered to the active Codex chat/context and the active task continued running, but the same turns remained visible in the composer/queue as failed items with exclamation indicators and Retry actions.

This is a false failure state: retrying is unnecessary and can duplicate instructions that have already been delivered.

What steps can reproduce the bug?

1. Start an active local task in the Codex desktop app on macOS.
2. Speak several Voice turns.
3. Confirm that the substantive transcript text reaches the active chat/context and the task continues.
4. Observe that those same Voice turns remain in the composer/queue with failed indicators and Retry.

No transcript text or task content is included in this report.

What is the expected behavior?

Completed Voice turns should enter the active chat promptly and directly. Once a turn has been delivered, it must not remain in a failed/retry queue state. Retry should be offered only when delivery actually failed.

Additional information

In-product feedback receipt: no-active-thread-01a04660-f539-7f10-b2ff-a25c1cbf24d9

Related but not duplicate:

• #21448 concerns a partial transcript.
• #21408 concerns failed transcription and lost audio.
• #28765 concerns failed transcription followed by loss of the pending dictation.
• #34600 concerns transcription failure where no text is inserted and Retry remains stuck.

Those reports do not describe transcript text already reaching the active chat while the same turns remain marked failed.

Privacy: attachments, logs, diagnostics, screenshots, and traces are NONE. No private conversation content, local paths, account identifiers, or task contents are included.

Update — August 29, 2026: window-change correlation and Steer duplication

This remains reproducible in ChatGPT Desktop 26.825.41651 (build 7345) on macOS 26.6.2.

A newly observed sequence adds two material details:

1. A Voice turn was substantively delivered and incorporated into the active conversation.
2. After navigating away from the Voice task/window and later returning, the already-delivered turn remained visible in the queue with a retry/error state.
3. Selecting Steer for that queued item injected the same already-delivered instruction into the conversation again.

This confirms the duplication risk: the stale queue entry is actionable even though delivery already succeeded. The window change is currently a correlation, not a proved cause, so the trigger should be classified as INTERMITTENT / NOT YET ISOLATED.

Expected behavior: once a Voice turn is accepted by the active conversation, every retry/error/Steer representation for that delivery should be cleared or marked delivered. A stale queue item must not be allowed to resend the same instruction without a clear duplicate-delivery warning.

Privacy: no transcript text, task content, private names, local paths, logs, screenshots, diagnostics, or legal material are included in this update.

No files or tests are named. Reproduce the macOS Codex Desktop Voice sequence, then trace the delivery, composer/queue, window-navigation, and Steer state transitions. Done means accepted turns are cleared or marked delivered, with no Retry or Steer action able to resend them.