[macOS][App] AirPods composer dictation stops itself while task and recording UI remain open

What version of the Codex App are you using?

26.814.41407 (build 6720)

What subscription do you have?

Not provided; the failure occurs in local microphone capture before model execution.

What platform is your computer?

macOS 26.6.1 (25G76), Apple Silicon.

What issue are you seeing?

Composer dictation with AirPods Pro intermittently starts normally and then stops by itself while the same Codex task and dictation/transcription window remain visibly open.

No keyboard or mouse input occurred, the shortcut was not pressed a second time, and there was no user-visible task or window change. Dictation works when switched to another microphone.

Sanitized local diagnostics from one occurrence show:

• The session used the composer surface and was marked completed after 25.524s.
• The Codex audio-service process opened the AirPods input successfully.
• After approximately 25 seconds, BluetoothHALPlugIn_StopIO was triggered by the Codex audio-service PID and stopped with error 0.
• No AirPods Bluetooth disconnect was observed; they remained connected and in-ear.
• An internal task-route/composer ownership rebind occurred 11ms before StopIO, despite no user-visible navigation or task change.

This suggests that the client is tearing down its own microphone session rather than the AirPods disconnecting. AirPods may be the trigger or contributing condition, but this report does not claim a proven root cause.

What steps can reproduce the bug?

1. Connect AirPods Pro and select them as the Codex voice input.
2. Open a Codex task and start composer dictation.
3. Continue speaking without touching the keyboard or mouse, pressing the shortcut again, changing tasks, or closing the dictation UI.
4. Observe that dictation may stop on its own while the same task and dictation/transcription window remain open.
5. Switch to another microphone; dictation continues to work in the observed setup.

The failure is intermittent, so more than one attempt may be required.

What is the expected behavior?

Recording should continue until the user explicitly stops it, changes context in a way that requires confirmation, or Codex displays a clear recoverable error.

What is the actual behavior?

Codex stops the active AirPods microphone session without user action and records the session as completed.

Additional information

• macOS microphone permission is granted.
• The AirPods microphone works with other dictation software.
• Selecting AirPods explicitly can improve input selection, but does not prevent this spontaneous stop.
• No raw audio, transcript content, device identifier, task identifier, local path, or unsanitized log is attached for privacy.
• Sanitized excerpts can be provided if useful.

Related but distinct reports:

• #29951 requires switching threads; no thread switch occurred here.
• #38324 stalls before recording starts; recording starts successfully here and then stops.
• #32249 concerns shortcut toggle/hold behavior; this stop occurred without a second shortcut event.

Start by reproducing composer dictation with AirPods Pro on macOS, then compare it with another microphone. Review the Codex audio-service diagnostics around the composer session completing after about 25 seconds, BluetoothHALPlugIn_StopIO, and the task-route/composer ownership rebind. Done means recording remains active without user action or produces a clear recoverable error, with coverage for the observed AirPods case.