Session Findings — 2026-04-29

What today's session learned that the prior debug log got wrong, what state the Mac is in now, and what to try next time.

Prior debug log was wrong about the root cause

The handoff doc (wispr-mouse-button-setup.md) said Karabiner-DriverKit was never approved. Not true. The DriverKit extension was already [activated enabled] per systemextensionsctl list. Real problem was different.

Actual root cause of the missing grabber

Karabiner v15 architecture moved away from a standalone karabiner_grabber binary. The grabber now lives inside two .app bundles registered via macOS's modern SMAppService API:

Both showed [disabled, allowed] in macOS's Background Task Manager (sfltool dumpbtm) even though the toggles in System Settings → General → Login Items & Extensions → App Background Activity appeared on. Known macOS bug — UI state desyncs from BTM state. Karabiner's own warning dialog actually states this:

"If these services are already enabled, the settings might not have been correctly applied on the macOS side. Try disabling them once and then enabling them again."

Fix that worked for Karabiner

In System Settings → General → Login Items & Extensions → App Background Activity, toggled both Karabiner items OFF then ON. After ~2 seconds:

$ pgrep -lf "Karabiner-Core-Service|VirtualHIDDevice-Daemon"
12411 .../Karabiner-Core-Service
12412 .../Karabiner-VirtualHIDDevice-Daemon

Karabiner config rule (button5 → ⌘\) is in ~/.config/karabiner/karabiner.json. Wispr Flow has ⌘\ as a push-to-talk shortcut.

Where the chain still breaks: the MX Ergo forward button never reaches the OS HID stack

With Karabiner fully running and configured correctly, pressing the ▲ button still produces zero pointing_button events in Karabiner-EventViewer. Logi Options+ owns the button at the driver level and consumes the event regardless of how it's mapped:

Logi Options+ mapping for ▲ Result
"Forward" (default) Consumed; raw HID never reaches Karabiner
"Do nothing" Silently consumed; no event of any kind
"Keyboard shortcut" with single key Field rejected synthesized CGEvents from automation, and physical key presses also did not register in this session
"Keyboard shortcut" with modifier combo Documented bug per prior session: combo records but doesn't fire when button is pressed

Killing logioptionsplus_agent is the only confirmed way raw pointing_button: button5 reaches the OS — that was your prior session's Attempt 9. But killing Logi loses Mission control, App expose, and Open folder mappings on other buttons.

What's still on the box

Persistent changes made today (won't revert on reboot):

Reversible / current Logi state:

Options to try next time

A. Different button. Map a less-claimed button (Mission control, Back, side buttons) to keystroke; some MX Ergo buttons may behave differently than the front-top under Logi.

B. Logi off, accept the loss. Permanent launchctl unload of com.logi.optionsplus.plist. Karabiner catches button5, Wispr fires. Other Logi mappings die.

C. Switch the MX Ergo to direct Bluetooth pairing (not via Logi Bolt receiver). This may let raw HID through even with Logi Options+ running. Untested.

D. Hyper-key combo in Logi. A 4-modifier chord like ⌘⌃⌥Shift+P may sidestep the Logi modifier-combo bug. Requires physically clicking Logi's shortcut field and pressing the chord — synthesized keystrokes are rejected by the field.

E. Status quo. Keep using ⌘D from the keyboard for push-to-talk. Forget the mouse.

Useful commands for the next session

# Karabiner state check
pgrep -lf "Karabiner-Core-Service|VirtualHIDDevice-Daemon"
sfltool dumpbtm | awk '/Karabiner-Elements/{found=1; print; next} found && /Disposition/{print; found=0}'

# Logi state check
pgrep -lf "logioptionsplus_agent" | grep -v updater

# Karabiner-EventViewer for live HID inspection
open -a "Karabiner-EventViewer"

# Kill Logi (option B above)
launchctl unload /Library/LaunchAgents/com.logi.optionsplus.plist
pkill -9 -f "/Applications/logioptionsplus.app"