[macOS] Dictation loses opening words: ~600 ms input gap after dictation-ducking starts

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

26.1027.30824, build 22943, verified from the installed bundle metadata. The unified desktop app is named ChatGPT, with bundle identifier com.openai.codex.

What subscription do you have?

Not included in this report.

What platform is your computer?

• macOS 27.2 (26B123); uname -mprs: Darwin 27.2.0 arm64 arm.
• MacBook Pro (MacBookPro18,2), Apple M1 Max, 64 GB RAM.
• Default input: MacBook Pro Microphone, 48 kHz. Default output: MacBook Pro Speakers.
• Configured app dictation shortcut: Ctrl+;. System input volume: 100%.

What issue are you seeing?

After the recent desktop app update, starting dictation with the configured shortcut and speaking immediately frequently loses the first one to three words. The waveform also becomes unusually small and barely reacts even to loud speech, although most subsequent speech is transcribed successfully.

A read-only investigation found actual discontinuities in locally saved audio, plus matching microphone stop/restart events in macOS logs. The strongest lead is the app's bundled dictation-ducking helper, which starts a separate VoiceProcessingIO audio unit after recording is already underway.

Key measurements:

For October 30, the median detected opening gap is 587 ms; the range is 145–911 ms. The cohort includes 168 composer and 30 global recordings. All 30 most recent eligible recordings in that snapshot have an opening gap.

These are audio-continuity measurements, not transcript error rates. They do not mean that every gap contained speech or that every affected recording lost the same number of words.

What steps can reproduce the bug?

This describes the affected normal-use workflow; a controlled synthetic reproduction has not been run.

1. Use the built-in MacBook Pro microphone and speakers with the app version above.
2. Focus a chat composer and invoke dictation with the configured app shortcut.
3. Begin speaking immediately after pressing it, using a sentence with a known opening.
4. Stop dictation and compare the opening words with the resulting text. Observe the waveform's response while speaking.
5. Inspect the corresponding saved audio's packet timestamps and macOS audio-device events.

The same opening-gap pattern is present in both composer and global recordings. In one user-confirmed example, the spoken opening “Though it” was missing and had to be typed manually. That recording is case A / R197 in the sanitized measurements.

What is the expected behavior?

Audio capture should remain continuous once recording is indicated. Starting or stopping playback ducking should preserve an active microphone stream and its channel/gain configuration. The waveform should remain a useful indication of the captured speech level.

Additional information

Sanitized evidence attachment: dictation-evidence.zip

The ZIP contains the 318-row packet measurements, summary metadata, normalized incident timeline, a read-only inspector, and file checksums. No recordings or full transcripts are attached.

ZIP SHA-256: 757694186e3ba4693f789776389a7b7aa28d9c8c77e6bfa91df948cee7cccc4a.

One incident correlated across app events, Core Audio, and saved packets

The following times are relative to the app's recording_started event for case A. Process IDs, device object IDs, and absolute activity times are omitted.

The microphone context is stopped for approximately 585 ms. In the corresponding WebM recording, packet coverage ends at 0.660 s and resumes at 1.255 s: a 595 ms discontinuity. The small difference is consistent with packetization and buffering; the clocks are not assumed to be sample-aligned.

The app therefore reports recording before a subsequent device interruption. Initial microphone-acquisition latency alone does not account for this second gap.

ffprobe -v error -select_streams a:0 -show_packets \
  -show_entries packet=pts_time,duration_time \
  -of json recording.webm

Why the ducking path is the leading hypothesis

• In this installed renderer, the dictation path calls dictationPlayback.duck() after capture begins. The returned lease is released when the recorder stops.
• The host launches native/dictation-ducking. Its component description is Apple auou / vpio / appl (VoiceProcessingIO). The helper disables input on bus 1, installs a silent render callback, initializes the unit, and starts output.
• Despite that input-disable setting, the incident logs show shared built-in microphone reconfiguration. The helper's logs report a microphone channel count changing from 1 to 3. A later idle inventory with no ducking helper running reports 1 input channel.
• The principal waveform RMS gate and normalization curve match an earlier inspected bundle, 26.1007.71326 / build 20398. This narrows one possible explanation for the tiny waveform; it does not exclude other UI changes.

Mozilla's audio engineers documented a closely matching macOS interaction: introducing VoiceProcessingIO can expose additional, low-level channels on the built-in microphone to another capture client. They also documented input/output freezing during VoiceProcessingIO reconfiguration. These are relevant precedents, not independent confirmation of the cause in this app:

• Mozilla bug 1910888, comment 5: built-in microphone channels and low levels.
• Mozilla bug 1880244: VoiceProcessingIO reconfiguration and interrupted audio.

app.asar
36bf3d2b35e95e11852074b9ca9459b89efbecd6b8311345d060cf66de8f0ba6

native/dictation-ducking
5c2a474552179a1e792e3a953638b6ec79cb95695f89f649ccd4a55f1703359c

Related reports and suggested investigation

• #58420 reports the same app build and helper, but concerns a Core Audio hang around dictation stopping on a different audio setup. This report concerns startup interruptions and low levels; a common cause is unconfirmed.
• #57400 reports missing opening words and premature recording feedback on Windows. The macOS VoiceProcessingIO mechanism discussed here has not been connected to that report.
• #58265 reports a missing familiar dictation indicator on the same build. Here an indicator exists but responds weakly; the UI symptoms are distinct.

Please investigate whether starting this independent, output-only VoiceProcessingIO unit after capture begins changes the shared built-in input format or interrupts its existing clients. A targeted next test would bypass only the optional ducking step in a diagnostic build, then compare packet continuity, the input channel format, and waveform levels. Any necessary device reconfiguration should settle before the app signals recording readiness.