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, PID 0xB025 Firmware MPM24.01_0015 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 s gap in raw HID reports from the mouse occurred 0.899 s before that event; bluetoothd then reported a HID lag issue for VID 0x046D, PID 0xB025 at +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: https://developer.apple.com/forums/thread/845857

Summary The Apple Developer Forums profile lets me enable push notification preferences, but Safari is never asked for permission. The profile still says that this browser has not opted in to receive pushes, so I cannot receive forum push notifications in Safari. Environment macOS 26.7 and Safari 26.6.2 on a Mac mini. Signed in to Apple Developer Forums at https://developer.apple.com/forums/profile/preferences. In Safari → Settings → Websites → Notifications, Allow websites to ask for permission to send notifications is enabled. developer.apple.com does not appear in the site list. Content blockers are disabled for developer.apple.com. Steps to reproduce Open the Apple Developer Forums profile preferences in Safari while signed in. Under Receive push notifications when, enable There's a response to my post or reply. Click Save Profile. Return to the profile preferences and check the browser opt-in status. I also turned this preference off and on again. Neither that action nor saving the profile displayed a Safari permission prompt. Expected result The forum offers a way to request Safari's notification permission and subscribe this browser to push notifications. Once permission is granted, the profile should show that this browser is opted in. Actual result No Safari notification permission prompt appears. The push preference remains checked after saving, but the profile says: “You haven’t opted in to receive pushes from Apple Developer Forums on this browser.” developer.apple.com remains absent from Safari's Notifications website list. In Safari Web Inspector on the forum profile page, Notification.permission returns "default", and (await navigator.serviceWorker.ready).pushManager.getSubscription() returns null. A service worker registration is present for the forums. This indicates that the browser has neither made a permission decision nor acquired a push subscription. I have not identified why the forum's opt-in flow does not reach the browser permission request.

I found that the failing corner in native macOS window tiling changes with the Dock position. With the Dock on the right, the upper-right corner produces the right half instead of a quarter. With the Dock on the left, the upper-left corner produces the left half instead of a quarter. With the Dock at the bottom, all four corners produce quarters. Apple's macOS Tahoe guide describes dragging to any corner as a way to tile a window there. Configuration Mac mini Mac14,12, Apple M2 Pro macOS Tahoe 26.7 (25G229) One external iiyama PL4071UH (ProLite X4071UHSU) display, with a [native panel resolution of 3840 × 2160]; no adjacent display and mirroring off. A 3840 × 2160 mode is available in macOS, but it was not the mode used for these measurements. Active macOS display mode reported by CGDisplayMode and System Information: 3008 × 1692 pixels at 60 Hz; the interface “looks like” 1504 × 846 points (2× backing scale). This is a scaled configuration on the 4K display. NSScreen.frame: 1504 × 846 points. NSScreen.visibleFrame with the Dock on the right: approximately 1456 × 816 points (about 48 points removed at the right for the Dock and 30 at the top for the menu bar). macOS reports Television: Yes for this display and exposes an Underscan control in Displays settings. The slider appeared at the “No” end during inspection; its effect on this tiling behavior has not been tested. Dock position changed between right, left, and bottom for the comparison below Dock auto-hide is currently off (com.apple.dock autohide = 0) Native drag-to-edge tiling and the Option-key tiling accelerator enabled; tiled window margins disabled Upper-right Hot Corner configured without a modifier key during the right-Dock measurement Steps to reproduce Open a blank, resizable TextEdit window and enable native drag-to-edge tiling. Set the Dock position to Right in System Settings → Desktop & Dock. Drag the window by its title bar to each screen corner and release after the tiling preview appears. Set the Dock position to Left and repeat. Set the Dock position to Bottom and repeat. Dock-position comparison Dock position Upper-left corner Upper-right corner Lower corners Right quarter right half quarters Left left half quarter quarters Bottom quarter quarter quarters The left- and bottom-Dock comparisons are direct user observations. The right-Dock case was also measured programmatically as described below. This pattern points to a side-Dock interaction with detection of the adjacent upper corner; the internal cause is not yet established. The display's scaled mode and its classification as a television are additional variables worth recording. Neither has been isolated as a cause: the controlled change so far is the Dock position. A useful follow-up would be to repeat the same corner tests at another display mode, including 3840 × 2160, with the Dock kept on the same side, and to record the Underscan setting. Instrumented result with Dock on the right I sampled NSEvent.mouseLocation every 20 ms, used CGEventSource.buttonState to identify the release, and read the window bounds using CGWindowListCopyWindowInfo about 0.6 seconds later. The same TextEdit window ID was observed for all four corner tests. Pointer and window coordinates below use the top-left of the display as (0, 0); dimensions are in macOS points. Release corner Pointer (x, y) Window (x, y, width, height) Result Top left (0, 0) (-1, 30, 727, 409) quarter Top right (1503.98, 0) (727, 30, 728, 816) RIGHT HALF Bottom left (0, 845.98) (-1, 438, 727, 409) quarter Bottom right (1503.98, 845.98) (727, 438, 728, 409) quarter At the upper-right release, the pointer is effectively at the screen's rightmost x coordinate and at y = 0. The resulting window is 816 points high, compared with 409 points for each quarter tile. The Hot Corner did not prevent the pointer from reaching that coordinate. Expected result Dragging to any of the four corners should produce the corresponding quarter regardless of whether the Dock is on the right, left, or bottom.