Unofficial archive. This is a read-only, community-run archive of the Apple Support Community. It is not affiliated with or endorsed by Apple Inc.

macOS audiomxd and configd processes show high CPU usage at login window

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


1 reply

One test that would narrow this down, since your stack points at BTAudioRoutingRequest: while it is spinning at the login window, power off or move out of range every paired Bluetooth audio device the mini knows (AirPods in their case still advertise, a BT speaker in standby counts), and watch top over SSH. If audiomxd drops within a minute or two, the loop is the routing retry against a device it cannot hand to a console session, and unpairing that device is a workaround until Apple fixes it. If nothing changes, the other place audiomxd loops come from is third party HAL drivers in /Library/Audio/Plug-Ins/HAL (meeting app audio drivers, virtual cables, and the like), worth listing what is in that folder.


Either way, this is a system daemon state bug, nobody here can patch it. The report that gets it fixed is a Feedback Assistant submission with a sysdiagnose captured while it is spinning at the login window, plus the spindump you already have. Your write up is honestly better than most reports Apple gets, I would attach it as is.