16.3.0: after some wakes, device_grabber matches no devices until reboot (daemon restart does not help)
Details
Environment
- Karabiner-Elements 16.3.0, Karabiner-DriverKit-VirtualHIDDevice 1.8.0
- macOS 26.6.2 (25G83), MacBook Pro (Mac16,5)
- Devices: built-in keyboard/trackpad, Alice 98 (USB, ISO), Logitech USB Receiver (USB), MX Vertical (Bluetooth LE)
enable_cgeventtap_fallback: false
Summary
After some wakes from sleep, the daemon logs device_grabber is started., but it matches no device after that:
- no
hid device events monitor is started (grabbed)line, - no
caps lock is found on ...line, - not even the
(observed)lines for Karabiner's own virtual devices.
All modifications stop. The daemon logs no error or warning, and all processes stay up. Restarting the agents or the daemon does not help. Only a reboot fixes it.
Frequency
core_service.log from Sep 1 to Sep 16 shows 76 wakes:
- 2 wakes left Karabiner in this state until a reboot (Sep 8 and Sep 16).
- 3 wakes had a first grabber start with no devices, but they recovered by themselves within seconds.
On Sep 16 the failure followed Idle Sleep on AC power with the lid open (pmset -g log). I cannot reproduce it on demand.
Log
These are selected lines from /var/log/karabiner/core_service.log on 2026-09-16. I removed the date and the [core_service (daemon)] tag. Between the wake at 13:50:39 and the reboot, the daemon logged no other device lines and no error or warning lines.
Healthy start before the sleep:
[13:32:11.547] [info] virtual_hid_device_service_client_ virtual_hid_keyboard_ready_response: true
[13:32:11.547] [info] virtual_hid_device_service_client_ virtual_hid_pointing_ready_response: true
[13:32:11.553] [info] Alice 98 (device_id:4295347530) hid device events monitor is started (grabbed).
[13:32:11.553] [info] USB Receiver (device_id:4295347708) hid device events monitor is started (grabbed).
[13:32:11.561] [info] Apple Internal Keyboard / Trackpad (device_id:4294970647) hid device events monitor is started (grabbed).
[13:32:11.587] [info] MX Vertical (device_id:4295363519) hid device events monitor is started (grabbed).
[13:32:11.612] [info] Karabiner DriverKit VirtualHIDKeyboard 1.8.0 (device_id:4295363665) hid device events monitor is started (observed).
[13:32:11.613] [info] Karabiner DriverKit VirtualHIDPointing 1.8.0 (device_id:4295363667) hid device events monitor is started (observed).Sleep, wake, and the failed state:
[13:33:41.304] [info] system_will_sleep
[13:33:44.320] [info] call IOAllowPowerChange
[13:50:39.419] [info] system_has_powered_on
[13:50:40.193] [debug] device_grabber is started.
[13:50:41.630] [info] virtual_hid_device_service_client_ virtual_hid_keyboard_ready_response: true
(no device lines follow)The machine then slept and woke two more times (13:51 and 13:59). After each wake, the grabber started again and matched no devices.
In the failed state, virtual_hid_keyboard_ready_response: true appears after every grabber start, but virtual_hid_pointing_ready_response never appears. A healthy start logs both.
What I tried
| Time | Action | Result |
|---|---|---|
| 14:04:40 | launchctl kickstart -k for gui/<uid>/org.pqrs.service.agent.Karabiner-Console-User-Server and ...Karabiner-Core-Service-rev2 |
The grabber started again. No devices. |
| 14:07:38 | Toggled Input Monitoring for Karabiner-Core-Service, then ran sudo launchctl kickstart -k system/org.pqrs.service.daemon.Karabiner-Core-Service |
device_grabber is not started because the required permissions are not granted. |
| 14:08:05 | Turned Input Monitoring on again | The required permissions are granted. Restarting core daemons. The new daemon started the grabber at 14:08:07. No devices. |
| 14:08:37, 14:09:26 | Restarted the daemon again (kickstart -k) |
No devices. |
| – | Opened the Karabiner-Elements settings window | It stayed on a loading indicator. |
| 14:13:27 | Rebooted | All devices grabbed at 14:14:09. |
After the reboot, enable_cgeventtap_fallback was true because of an unrelated config change, which I have since reverted. The healthy start at 13:32 had false.
Related issues
- #4515 has the same symptom. There, restarting the core service fixed it. Here it does not.
- #4544 describes a dead zone after wake, fixed in 16.2.0. Here the failed state lasts until a reboot.
Question
I cannot trigger this on demand. What should I capture the next time it happens, before I reboot? For example, a sample of the root Karabiner-Core-Service, or a specific log stream predicate.
Drafted with Claude Code from my logs. The log lines are verbatim.
Source: pqrs-org/Karabiner-Elements