coreaudiod pinned at ~9% CPU: notification sound leaks BuiltInSpeakerDevice audio stream (regression of #24668) #35242

Summary

coreaudiod gets pinned at ~9% CPU indefinitely after opencode plays a completion/notification sound. The one-shot sound opens a BuiltInSpeakerDevice audio-output stream that is never torn down, so macOS keeps the Core Audio output engine running (and holds a PreventUserIdleSystemSleep power assertion) for the entire lifetime of the opencode process. CPU drops to 0% the instant opencode exits.

This is the same class of leak as the closed #24668 (logo charge-hum audio leak), reproducing on the current release — appears to be a regression / incomplete fix.

Environment

• opencode: 1.17.13 (latest; matches npm [email protected] and release v1.17.13)
• macOS: 15.7.5 (24G624), Apple Silicon (arm64)

Steps to reproduce

1. Run an opencode session with the completion/notification sound enabled.
2. Trigger a notification (e.g. let an assistant response complete so the "ding" plays).
3. Observe coreaudiod CPU with top/ps.

Expected

The notification sound is a fire-and-forget one-shot. After it finishes, opencode should release the audio output stream so coreaudiod returns to idle (~0%).

Actual

opencode keeps the output stream open for the whole session. coreaudiod sits at ~9% CPU continuously and drops to 0% only when opencode exits. Every subsequent notification re-opens a fresh leaked stream.

Evidence

Persistent power assertion owned by the opencode PID (survives long after the sound ended):

$ pmset -g assertions | grep -A2 BuiltInSpeakerDevice
pid 10974(coreaudiod): [...] PreventUserIdleSystemSleep named:
  "com.apple.audio.BuiltInSpeakerDevice.context.preventuseridlesleep"
  Created for PID: 15075.        <-- opencode session PID
  Resources: audio-out BuiltInSpeakerDevice

opencode PID holds the CoreAudio output component open:

$ lsof -p 15075 | grep CoreAudio
opencode. 15075 ... /System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio

coreaudiod CPU while the (idle, silent) stream is held:

$ ps -o pid,%cpu -p $(pgrep coreaudiod)
  PID  %CPU
10974   9.3

Watched a fresh stream appear ~40s after a notification played, confirming each sound re-triggers the leak. Over a long-lived session (27-day uptime here), leaked streams accumulated and coreaudiod had burned ~31 CPU-hours.

Workaround

Disabling the completion/notification sound stops the leak entirely (no sound played → no output stream opened → coreaudiod stays at 0%).

Related

• [BUG] Logo charge-hum audio leaks after mouseout: coreaudiod pinned at 480% CPU, painful continuous noise on output device #24668 (closed) — same audio-stream-leak mechanism (logo charge-hum)
• Desktop notification sound plays repeatedly upon opening and can't be dismissed #15302, [Desktop] Repeated error alert sounds on startup caused by unhandled node-pty AttachConsole failure #32389 — notification sound path