audiomxd and configd spin at high CPU while the Mac sits at the login window (BTAudioRoutingRequest retries with no console user)
SUMMARY
When no user is logged in at the console, audiomxd uses about 75-79% of a CPU core and configd about 41-42%, indefinitely. On my Mac mini it ran for 3.4 days, from a console logout until the next console login. Logging in at the console (Screen Sharing works) drops both to 0% within seconds; an ssh login does not.
ENVIRONMENT
- Mac mini Mac16,10 (Apple silicon, 16 GB), macOS 27.0.1 (26A434)
- Headless server: no display, keyboard or mouse; reached over ssh and Screen Sharing
- Audio: built-in speakers only, no input device. Bluetooth on, no paired devices
- FileVault off, no automatic login
STEPS TO REPRODUCE
1. Log the console user out so the Mac sits at the login window.
2. Within about 2 minutes, check top over ssh: audiomxd about 75%, configd about 40%.
3. Log in over ssh: no change.
4. Log in at the console: both drop to about 0%.
MEASUREMENTS (CPU time from ps -o time between two readings)
- At the login window, 459 s: audiomxd 344 s (75%), configd 187 s (41%)
- Logged in through Screen Sharing, 15 s: audiomxd 0.00 s, configd 0.01 s
- Since boot (19 days): audiomxd 59.7 h, configd 33.9 h, which fits continuous spinning since the logout 3.4 days earlier
macOS also wrote a cpu_resource report for audiomxd 2 minutes after the logout: 90 s of CPU in 149 s, "Action taken: none".
HEAVIEST STACK (from that report)
11 -[BTAudioRoutingRequest updateAudioState:withState:]_block_invoke (AudioAccessoryServices)
10 -[BTAudioRoutingRequest _ensureXPCStarted]
10 SCDynamicStoreCopyConsoleUser (SystemConfiguration)
6 configget -> mach_msg (to configd)
4 _SCUnserialize -> CFPropertyListCreateWithData
UNIFIED LOG (audiomxd, repeating)
BTAudioRoutingRequest: ### TargetUserSession, but no console user?
BTAudioRoutingRequest: ### UpdateAudioState failed to start XPC: kUnexpectedErr (No user logged in)
BTAudioRoutingRequest: ### audioaccessoryd died
MXSessionManager audioAccessoryServerDiedCallback: Syncing with AudioAccessoryServices as they just recovered.
ANALYSIS
audioaccessoryd runs only inside a logged-in user session; at the login window it was not running and /dev/console was owned by root. Each audio state update calls _ensureXPCStarted, which asks configd for the console user, gets none and fails. The failure is treated as "audioaccessoryd died", the resync queues another update, and the cycle repeats with no backoff. Every attempt is a request to configd, which explains its CPU use.
Suggested fix: while there is no console user, stop retrying and wait for a console-user change notification, instead of treating it as a server death.
WORKAROUND
Stay logged in at the console; automatic login covers reboots. According to the reports below, killing audiomxd only helps for about 5 minutes.
RELATED REPORTS (none with a confirmed cause)
- Jamf Nation, "audiomx process maxed out" (2025): login window on lab Macs, and a Mac mini 10-15 minutes after logout; one poster stopped it by turning Bluetooth off. https://community.jamf.com/general-discussions-2/audiomx-process-maxed-out-34938
- cfarm-users list (Feb 2026), a headless Mac in a data center: https://lists.tetaneutral.net/pipermail/cfarm-users/2026-February/001469.html
- Apple Community thread 255974341 (2025), mostly with audio routed to external displays: https://discussions.apple.com/thread/255974341