macOS: dictation startup stalls with Audio visualizer enabled; changing volume releases it

Environment: ChatGPT/Codex desktop 26.903.61454 (8378), macOS 26.6.2 (25G83), Apple Silicon.

Over the last 1–2 days, dictation intermittently stalls on “Starting dictation…” and the composer/task becomes unresponsive. It happens in both local and remote devbox tasks, particularly when starting another dictation immediately after a previous one. Restarting the app does not resolve it. It reproduces with the built-in microphone and speakers and AirPods disconnected.

Changing Mac volume appears to release the stall quickly. Turning off Toys → Audio visualizer appears to help in initial testing; a controlled re-enable test has not yet been completed. After disabling it, the system-audio-spectrum helper was no longer running.

Reproduction

1. Enable Audio visualizer in Toys settings.
2. Use the built-in microphone and speakers.
3. Start and stop several consecutive composer dictations.
4. If startup stalls, press a volume key and observe whether recording resumes.
5. Compare with Audio visualizer disabled.

Captured evidence (September 10, 2026, PDT)

• 10:33:40.638: Dictate click.
• 10:33:40.776: CoreAudio begins BuiltInMicrophoneDevice startup for the Codex audio-service process.
• 10:33:54.784: StartIOThread reports error 0x3C, about 14 seconds later.
• 10:33:59.100: BuiltInSpeakerDevice volume changes.
• 10:33:59.205: CoreAudio logs “Starting tap after waiting for writers”.
• 10:33:59.227: The app’s system-audio-spectrum helper is reported running.
• 10:33:59.353: Codex’s audio-service recording client is reported running, 253 ms after the volume change.
• An earlier attempt at 10:33:00 also had an approximately 14-second microphone-start failure.

Installed-app code inspection connects system-audio-spectrum to the optional conversation-rail Audio visualizer. This suggests an interaction between system-audio capture and microphone startup, but does not establish whether the root cause is the helper, Chromium audio, or CoreAudio. Process samples were captured after the recorded failure and are not claimed to show the blocked call.

Related symptom report: https://github.com/openai/codex/issues/38324

Please investigate Audio visualizer audio-tap lifecycle interaction with repeated microphone capture startup. This report intentionally excludes raw logs, recordings, account information, and task metadata.

Start by reproducing repeated composer dictation with the Audio visualizer enabled and disabled, using the built-in microphone and speakers. Inspect the optional conversation-rail audio-tap lifecycle alongside microphone startup, using the supplied CoreAudio timestamps and volume-change behavior; done means the interaction causing the stall is identified and corrected.