[macOS][26.1027.30824] Stopping composer dictation correlates with Core Audio hang affecting other apps

Prepared and submitted by OpenAI Codex on behalf of the affected user, at their explicit request, after working interactively with them to troubleshoot the symptoms and review local diagnostics. The user confirmed the symptoms and recovery; the analysis below distinguishes observations from hypotheses. This public report contains only reviewed technical details and sanitized excerpts.

What version of the Codex App are you using?

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

What subscription do you have?

Not included for privacy.

What platform is your computer?

• Apple Silicon MacBook Pro; macOS 27.0.1 (26A434).
• System default input: Focusrite Vocaster One USB, 48 kHz. Its reported 10 input / 4 output channels are logical interface channels, not ten physical microphones.
• Default output: CalDigit TS4 Audio - Rear, 48 kHz.
• Affected third-party dictation application: MacWhisper 15.8 (1580).
• Virtual audio components present: Rogue Amoeba ARK 13.5.2 / Loopback Audio, SquirrelsLoopbackAudioDriver 1.0.2 / Squirrels Audio. They were not removed or isolated, so neither is established as the culprit.

What issue are you seeing?

On October 30, 2026, two incidents on the same Mac, separated by a reboot, followed a closely matching sequence: built-in composer dictation starts successfully, the bundled dictation-ducking helper activates Apple's voice processor, and Core Audio becomes stuck around dictation stopping.

The impact extends beyond the app:

• The user reports that built-in dictation subsequently says no microphone is available.
• MacWhisper freezes; its sampled main thread is blocked while enumerating the default audio device through Core Audio server IPC.
• The macOS System Settings Sound panel fails to open normally, according to the user.
• A native system_profiler SPAudioDataType query hangs.
• The USB registry still shows the Vocaster connected. This was not an observed physical USB disappearance.
• Restarting only coreaudiod restores immediate device enumeration and both dictation applications, without rebooting the Mac.

The user associates onset with a desktop app update that morning. Current build metadata is verified; file timestamps and an updater signature-validation event are consistent with a morning update, but the captured updater message does not name its target. We have not established the previous app build or performed a rollback comparison. MacWhisper and the third-party HAL-driver bundle timestamps predate this incident day.

Observed sequence and reproduction limits

This is intermittent, with two naturally occurring failures rather than a deterministic minimal reproduction. Some other dictation sessions completed without a subsequent observed hang.

1. Use the unified ChatGPT/Codex desktop app with the USB interface selected as the system default input and the audio components above present.
2. Start built-in composer dictation. App events reach permission_ready, microphone_ready, first_audio, and recording_started.
3. Speak, then stop dictation. In the two affected attempts, stop_requested occurred approximately 19.565 seconds and 7.221 seconds after the respective starts. Both app attempts subsequently logged completed; that did not establish that the shared audio service remained healthy.
4. About 2.3 seconds after each stop request, Core Audio emits its first Monitor::BeginWriteOperation: still waiting after 2000 ms warnings on two device-change queues. The reported wait duration places the beginning of the waits near the stop requests.
5. In the later incident, the helper destroys its voice processor and exits about 0.32 seconds after stop_requested, near the apparent beginning of the wait.
6. The waits continue growing for minutes, and other audio consumers become affected as described above.

During both sessions, Core Audio also logged hardware-reference-stream changes and DSP negotiation involving MacWhisper, Firefox and virtual audio devices. Errors included unsupported DSP configurations and invalid configuration-change dictionaries. These are surrounding observations, not proof of the faulty component.

Sanitized diagnostics

The following are selected message/stack excerpts. Absolute timestamps, process/thread IDs, memory addresses, device/context IDs, serials and device UUIDs have been omitted. Entries grouped here are not a complete consecutive trace.

dictation-ducking:
  creating AUVoiceProcessor...
  voice processing is not bypassed

coreaudiod:
  HALS_PlugInDevice::ConfigChange_HardwareReferenceStream
  don't perform VI on virtual device input streams
  unsupported configChangeRequest - devices
  Unsupportable configuration for DSP
  Invalid primary stream - cannot build context info
  Missing top level description entry from the config change dictionary!
  Invalid config change dictionary received!
  Failed to convert the config change request dictionary

coreaudiod, after dictation stop:
  Monitor::BeginWriteOperation: still waiting after 2000 ms.
  RIP: 1 RP: 0 WIP: 0 WP: 1
  GroupPropertiesChanged_Sync, PlugInDevice Change Queue [device ID omitted]

MacWhisper's main thread was sampled as blocked along this path before recovery:

AVCaptureHALDevice defaultDeviceWithDeviceType:mediaType:position:
AudioObjectGetPropertyData_mac_imp
HALDefaultDeviceProperty::GetDefaultDeviceIDFromServer
HALC_ShellPlugIn::ReconcileDeviceList
HALC_ShellPlugIn::_ReconcileDeviceList
HALC_ProxyObject::GetPropertyDataSize
HALC_Object_GetPropertyData_DAI32
mach_msg / mach_msg2_trap

Apple's avconferenced produced a diagnostic approximately 42 seconds after the stop request in each incident. Both diagnostics contain the same timeout-handler path on the faulting thread:

VCTerminateProcess
+[VCXPCConnection selfTerminateDueToTimeout:]
_VCXPCConnection_timeoutHandlerFunc

Both reports show EXC_BAD_ACCESS / SIGSEGV with that timeout-triggered termination path. They are treated as associated service timeouts, not proof of an independent exploit or the originating defect. A privileged pre-recovery coreaudiod stack was not captured, so the exact lock owner is unknown.

Recovery and checks performed

• An earlier full Mac restart temporarily cleared the issue; it recurred later with the matching sequence above.
• During the later incident, the user explicitly authorized interrupting audio, and coreaudiod was terminated with SIGTERM using macOS administrator authentication. The service restarted automatically.
• After this reset, system_profiler SPAudioDataType completed in approximately 0.33 seconds and still identified Vocaster One USB as the default input.
• A subsequent MacWhisper sample showed its main thread back in its normal event loop.
• The user then successfully tested both built-in composer dictation and their usual MacWhisper shortcut.
• Installed app/helper code-signature checks passed with OpenAI's developer identity. MacWhisper and the Rogue Amoeba/Squirrels driver checks also passed under their developers' identities. This is an integrity observation, not proof of bug-free software.
• No driver, privacy grant, microphone preference or security setting was changed during recovery. No virtual-driver removal comparison, audio-visualizer disable comparison, or old-versus-new app build comparison was performed.

What is the expected behavior?

Stopping composer dictation should release or restore its audio resources without leaving Core Audio's device-change notification paths blocked. Other microphone clients, device enumeration, and macOS Sound settings should remain responsive. If capture fails, the app should present a recoverable error without requiring an audio-service restart.

Working hypothesis and related reports

The strongest observed lead is an audio cleanup/teardown interaction around stopping built-in dictation, involving dictation-ducking, Apple's audio/voice-processing machinery, and possibly the installed audio routes. Temporal correlation is not a traced diagnosis; we cannot yet assign the defect to OpenAI code, macOS or a third-party driver.

• #58265: missing dictation waveform/recording indicator on the same app build. The affected user also reports a missing familiar waveform indicator after the update. A common root cause is unconfirmed.
• #42998 and #42229: audio-visualizer-related microphone failures, including effects across applications. These are relevant capture-lifecycle precedents, but their conversation-switching/visualizer triggers were not reproduced or isolated here. A system-audio-spectrum process was observed during troubleshooting after the later hang was already in progress; that does not establish its state at onset or rule its participation in or out.

Please investigate the dictation stop / ducking-helper teardown path and device-change/voice-processing interactions, including how these coexist with virtual audio devices and other microphone clients.

Privacy

No recordings, transcripts, conversation screenshots, session IDs, account/subscription details, local usernames/home paths, hostnames, network addresses, serial numbers, device UUIDs, or raw log/diagnostic files are attached. Technical excerpts above have been scrubbed, and event timings are relative rather than revealing the user's local activity times.