I am seeing a repeatable interaction between audio activity or audio-device discovery and a Bluetooth LE HID mouse on a Mac mini M2 Pro. Opening the detailed Sound panel in Control Center, or changing the HDMI audio output, makes the pointer stutter. Opening Apple’s Music.app has also caused a temporary complete loss of the mouse. In the worst cases, the mouse becomes completely unavailable and does not recover without Bluetooth troubleshooting or re-pairing.
Configuration
- Mac mini
Mac14,12, Apple M2 Pro, 32 GB RAM - macOS Tahoe 26.7 (
25G229) - Also reproduced on macOS Tahoe 26.1 (
25B78) - Logitech MX Anywhere 3 Mac over Bluetooth LE
- VID
0x046D, PID0xB025 - Firmware
MPM24.01_0015
- VID
- Logitech MX Keys M Mac over Bluetooth LE
- PL4071UH display and audio output over HDMI
- Logi Options+ installed
Trigger
- Connect the MX Anywhere 3 Mac and MX Keys over Bluetooth.
- Open Control Center from the menu bar.
- Open the detailed Sound panel, or change the HDMI audio output.
- Move the Bluetooth mouse continuously while audio-output discovery is taking place.
The issue is intermittent, but it has been reproduced several times on both macOS 26.1 and 26.7. Pointer stuttering can continue after the Sound panel is closed.
A later incident occurred when I opened Apple’s Music.app. The Bluetooth mouse became unavailable again, but this time it recovered automatically after approximately ten seconds. The Sony WH-1000XM6 headset was connected over Bluetooth, while the 512 GB USB flash drive was not connected. This shows that the USB drive is not required for a temporary mouse loss and makes concurrent Bluetooth audio activity a more relevant condition to investigate. The additional trigger suggests that the problem may not be limited to the Control Center interface itself and may also be associated with audio-subsystem initialization or audio-device activity. This is an observation, not yet a confirmed causal link.
Additional condition in the permanent-loss cases
In every incident where the mouse did not recover on its own and became effectively unusable, the following two devices were also present:
- a Sony WH-1000XM6 wireless headset connected over Bluetooth;
- a 512 GB SanDisk USB flash drive connected to the Mac.
I am reporting this as a correlation, not as a confirmed cause. The headset adds simultaneous Bluetooth audio activity. The USB drive may or may not be relevant depending on its USB mode, activity, shielding, physical location, and possible 2.4 GHz interference. The 512 GB capacity is included only to identify the device. Less severe cursor stuttering has also been observed around Sound-panel discovery; the two devices above are specifically the common condition I recorded during the permanent mouse-loss incidents.
Observed result
- The pointer starts stuttering and raw mouse HID reports develop multi-second gaps.
- In severe incidents, the Bluetooth mouse stops working entirely.
- Opening Music.app has also caused a temporary complete loss of the mouse; during that incident the Sony WH-1000XM6 was connected over Bluetooth, the USB flash drive was not connected, and the mouse recovered automatically after approximately ten seconds.
- Logi Options+ then displays the mouse as inactive.
- The mouse disappears from the IOHID tree, while the Bluetooth keyboard can remain present.
- A wired USB mouse remains responsive, so the Mac and pointer rendering are not completely frozen.
- The failure can persist after the Sound panel is closed.
Relevant logs
On macOS 26.7, bluetoothd repeatedly recorded the following sequence for the MX Anywhere 3 Mac:
MX Anywhere 3 Mac needs low latency
current connection parameters: interval 30.00 ms, latency 0
connection changed to: interval 7.50 ms, latency 44
Device "MX Anywhere 3 Mac" is Incompatible LE HID
Device "MX Anywhere 3 Mac" does not have _HID_SERVICE_
Connection timed out
disconnect result: 307
BLEPaired HIDBadBehavior Central
The sequence repeated during automatic reconnection attempts. The mouse later recovered on some occasions, but other incidents required turning Bluetooth off for about 15 seconds, turning it back on, forgetting the mouse, and pairing it again.
Instrumented reproduction
During a monitored reproduction on macOS 26.1:
- detailed audio discovery started at
+21.333 s; - a
2.400 sgap in raw HID reports from the mouse occurred0.899 sbefore that event; bluetoothdthen reported a HID lag issue for VID0x046D, PID0xB025at+1.897 s;- no display-frame gaps were detected;
- there was no sustained CPU saturation.
This indicates that the interruption is already present in the raw HID input stream. It does not appear to be only a cursor animation or WindowServer rendering delay.
Expected result
Discovering or switching audio outputs should not alter a separate BLE HID mouse connection, cause multi-second HID report gaps, remove _HID_SERVICE_, or disconnect the mouse.
Technical points for investigation
Could this be a macOS Bluetooth/HID connection-parameter or service-discovery problem triggered by concurrent audio discovery? In particular, why does macOS change the mouse from 30 ms / latency 0 to 7.5 ms / latency 44, then classify it as Incompatible LE HID, lose _HID_SERVICE_, and eventually disconnect it with result 307?
Has anyone reproduced the same sequence with a Logitech BLE mouse, a Bluetooth audio headset, or a USB 3 storage device connected?
The issue was also submitted through Apple’s public macOS feedback form on 24 September 2026. That form confirmed receipt but did not provide an FB case number.
Possibly related report
Another Developer Forums report describes a different BLE HID device with Incompatible LE HID and disconnect result 307 on macOS 27. The hardware and trigger are different, but the Bluetooth/HID failure signature may be related:
