›_ Codex Issues
Codex Issues / #19126

Codex Chronicle triggers high coreaudiod CPU with Rogue Amoeba ARK / SoundSource

Resolved 💬 3 comments Opened Apr 23, 2026 by cyberpapiii Closed Apr 23, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

Bug Report: Codex Chronicle triggers high coreaudiod CPU with Rogue Amoeba ARK / SoundSource

Summary

When Codex Chronicle is enabled on macOS with Rogue Amoeba SoundSource installed, the codex_chronicle screen recorder appears to trigger repeated Rogue Amoeba ARK audio meta-device register/unregister churn inside coreaudiod. This drove coreaudiod to roughly 100-130% CPU and made system audio controls laggy.

Disabling Chronicle and stopping codex_chronicle immediately reduced coreaudiod to roughly 11-30% CPU.

Environment

  • macOS: 26.5, build 25F5042g
  • Codex desktop: 26.417.41555
  • SoundSource: 6.0.6
  • Rogue Amoeba ARK driver installed
  • Krisp and Parrot virtual audio drivers also installed

Actual Behavior

While Chronicle is active:

  • coreaudiod sustains roughly 100-130% CPU
  • WindowServer sustains roughly 40-50% CPU
  • system volume/audio controls become laggy
  • coreaudiod logs show repeated ARK meta-device work tied to codex_chronicle

Representative log pattern:

HALS_MultiTap.cpp:222 register_meta_device
HALS_Client.cpp:1573 AddMuter: Process codex_chronicle (...) muted by com.rogueamoeba.ARK...
HALS_MultiTap.cpp:231 unregister_meta_device

Expected Behavior

Chronicle screen recording should not cause sustained high coreaudiod CPU or repeated ARK audio meta-device creation/destruction. If Chronicle is not intentionally recording audio, it should avoid triggering audio capture/muting paths entirely.

Reproduction Steps

  1. Use macOS with SoundSource / Rogue Amoeba ARK installed.
  2. Enable Codex Chronicle:

``toml
[features]
chronicle = true
``

  1. Launch Codex desktop.
  2. Confirm Chronicle is running:

``bash
pgrep -alf 'codex_chronicle|capture-screenshot-child'
``

  1. Observe process CPU:

``bash
ps -A -o pid=,%cpu=,%mem=,time=,command= | egrep 'coreaudiod|WindowServer|codex_chronicle|SoundSource|ARK' | sort -k2 -nr
``

  1. Observe coreaudiod logs:

``bash
log show --last 2m --style compact --predicate 'process == "coreaudiod"' \
| rg 'codex_chronicle|register_meta_device|unregister_meta_device|AddMuter'
``

  1. Stop codex_chronicle:

``bash
pkill -f '/Applications/Codex.app/Contents/Resources/codex_chronicle'
``

  1. Re-measure. In my repro, coreaudiod dropped from triple-digit CPU to roughly 11-30%, and the repeated ARK log entries stopped.

Workaround

Set:

chronicle = false

in ~/.codex/config.toml, stop the running codex_chronicle helper, and restart Codex.

Suggested Fix Direction

  • Ensure Chronicle does not trigger audio capture or audio muting paths when only screen capture is needed.
  • Keep Chronicle's capture client stable instead of causing repeated ARK meta-device creation/destruction.
  • Consider excluding codex_chronicle from audio capture/muting.
  • Add telemetry/guardrails for sustained coreaudiod load caused by Chronicle.

View original on GitHub ↗

3 Comments

cyberpapiii · 4 months ago

Follow-up from more isolation testing because I do not want to keep Chronicle disabled permanently:

  1. Adding /Applications/Codex.app to SoundSource's Excluded Applications list was not sufficient. A controlled Chronicle run still pushed coreaudiod to roughly 129% CPU.
  1. Adding the exact hidden executable /Applications/Codex.app/Contents/Resources/codex_chronicle to SoundSource's Excluded Applications list partially helped. In the sampled window I no longer saw codex_chronicle-specific ARK AddMuter log entries, but coreaudiod still sat around 50% CPU while Chronicle ran.
  1. Quitting SoundSource and temporarily booting out Rogue Amoeba's ARK launch agent (com.rogueamoeba.arkaudiod) fully mitigated the CoreAudio spike in the sampled run. With Chronicle running and ARK unavailable, coreaudiod sampled at 0.0% CPU. WindowServer remained high, which appears to be the ordinary screen-capture path rather than the CoreAudio bug.

Current local compromise:

  • Chronicle is enabled again with chronicle = true
  • SoundSource exclusions include both Codex.app and the exact codex_chronicle executable
  • This is only a partial mitigation; the fully clean local workaround is to avoid running Rogue Amoeba ARK/SoundSource while Chronicle is active.
cyberpapiii · 4 months ago

Additional retest after updating Loopback/SoundSource. Installed versions are now:

ARK.driver = 13.1.2
Loopback = 2.4.9
SoundSource = 6.0.6

With Chronicle enabled, SoundSource running, ARK 13.1.2 loaded, and both Codex.app and exact codex_chronicle SoundSource exclusions present, a controlled 20 second Chronicle run produced:

coreaudiod: ~49.5% CPU while Chronicle ran
WindowServer: ~43.9% CPU while Chronicle ran
SoundSource: ~6.5% CPU
arkaudiod: ~3.3% CPU

The sampled coreaudiod logs no longer showed codex_chronicle-specific ARK AddMuter / register_meta_device / unregister_meta_device entries.

After stopping Chronicle:

coreaudiod: ~12-13% CPU
SoundSource: ~3%
arkaudiod: ~0-2%

Interpretation: ARK 13.1.2 plus exact SoundSource exclusions appear to fix the earlier codex-specific ARK log spam, but Chronicle still causes a significant CoreAudio CPU increase while ARK/SoundSource is active. This is improved, but not fully fixed.

etraut-openai contributor · 4 months ago

This feature is still under development, so we're not accepting bug reports at this time. We'll mark it as "experimental" when it's ready for external use.