[macOS] Switching conversations with Audio visualizer enabled breaks voice input across apps

Switching conversations with Audio visualizer enabled repeatedly prevents voice input from starting in Codex and in third-party input methods on macOS.

Codex App version and platform

• Codex desktop app version 26.901.41123, build 7942 (from the installed app's Info.plist; bundle identifier com.openai.codex).
• macOS 15.7.2, Apple Silicon / arm64, MacBook Air.
• Default input: built-in MacBook Air microphone, mono, 48 kHz.

Steps to reproduce and observed behavior

1. With Audio visualizer enabled, switch between Codex conversations/tasks.
2. Try voice input. Codex voice input and the WeChat and Doubao input methods can become unable to start recording, including outside Codex. The input-method UI stays at 准备录音中 (Preparing to record).
3. Terminate only the app's system-audio-spectrum helper, leaving Codex and coreaudiod running. Voice input recovered during testing.
4. Switch conversations again. A new system-audio-spectrum process appeared and voice input failed again. This sequence was observed more than once.
5. Disable Settings → General → Toys → Audio visualizer. The user then reported that voice input continued working when switching conversations during the subsequent test.

Troubleshooting and limits of the evidence

• Restarting coreaudiod temporarily restored voice input, but the problem returned while the visualizer remained enabled.
• iFlyrec and Oray virtual audio components were temporarily removed from the HAL directory and the audio service restarted. The problem still recurred on conversation switching. After disabling the visualizer, those components were restored and reloaded; voice input remained functional during the subsequent test. Their removal is therefore not required for the observed workaround.
• Earlier system logs included HALS_IOContext_Legacy_Impl::StartIOThread: got an error from starting the IO thread, Error: 0x3C and Initialize failed - thread hasBeenStopped: 1 and shouldExit: 1. These errors were not consistently present on later reproductions and do not establish the root cause.
• Core Audio snapshots did not report an exclusive/hog owner for the audio devices. We have not established that the helper exclusively locks the microphone or identified the exact underlying audio-session failure.

The main additional finding is that conversation switching appears to retrigger the issue and it can affect third-party voice input system-wide, not just Codex Dictation. Disabling Audio visualizer is the working workaround in this environment so far.

No private conversations, recordings, account details, or full logs are included.

Expected behavior

Switching Codex conversations should not interrupt or prevent microphone recording in Codex or other applications. Audio visualizer should coexist with voice input and release its capture resources correctly.

Subscription

Not provided.

Related issue

Related to #42229. This report documents conversation switching as a repeated trigger, effects on third-party input methods, and a different app/macOS version.

Start by tracing the Audio visualizer setting, the system-audio-spectrum helper, and the conversation-switching path described in the report. Reproduce repeated conversation switches on macOS with the visualizer enabled while testing Codex and another input method. Done means switching conversations no longer prevents microphone recording and the helper releases capture resources correctly.