Since macOS 26.4 Beta 1, virtual HID devices created via DriverKit can no longer intercept key events from the built-in MacBook keyboard. External keyboards still work. This is confirmed and tracked here: https://github.com/pqrs-org/Karabiner-Elements/issues/4402 One possible lead (from LLM-assisted analysis of Apple's open-source IOHIDFamily code and cross-referencing community reports): macOS 26.4 Beta may have introduced or modified a security policy referred to as com.apple.iohid.protectedDeviceAccess, which could block IOHIDDeviceOpen for the Apple Internal Keyboard connected via SPI transport (AppleHIDTransportHIDDevice). This appears related to a "GamePolicy" check in IOHIDDeviceClass.m that gates whether processes can open HID devices. This has not been independently verified and may or may not be the root cause. This has far-reaching consequences. Karabiner-Elements alone has over 21,000 GitHub stars and is used by hundreds of thousands of macOS users for keyboard customization, accessibility workflows, ergonomic setups, and multilingual input. This change completely breaks its core functionality on any MacBook. Beyond Karabiner, this affects every developer building keyboard remapping, input customization, or accessibility tooling via DriverKit virtual HID devices — including commercial applications currently in development. I'd argue that the power and flexibility of keyboard customization on macOS is a genuine competitive advantage for the platform. Developers and power users choose Macs partly because tools like this exist. Restricting this capability would be detrimental to the ecosystem and to Apple's appeal among professional users. I'd like to understand: is this an intentional security change or a regression? If intentional, is there a migration path?

macOS 26.4 Beta appears to have changed how built-in MacBook keyboard events are routed through IOHIDSystem. Third-party virtual HID devices loaded via DriverKit no longer receive events from the built-in keyboard. External keyboards are unaffected. This is already confirmed across multiple users: https://github.com/pqrs-org/Karabiner-Elements/issues/4402 One possible lead (from LLM-assisted code analysis, not independently verified): this could be related to a security policy referred to as com.apple.iohid.protectedDeviceAccess, which may block IOHIDDeviceOpen for the Apple Internal Keyboard via SPI transport (AppleHIDTransportHIDDevice). A "GamePolicy" check in IOHIDDeviceClass.m that gates HID device access could be involved. This is a hint, not a confirmed root cause. The impact goes well beyond a single project. Keyboard remapping on macOS is a thriving ecosystem — used for accessibility, ergonomics, developer productivity, and multilingual input. This is one of macOS's strengths as a platform. Many professionals specifically choose Mac because this level of customization is possible. If this capability is being removed without an alternative, it would significantly diminish what makes macOS attractive for power users and developers. Is this an intentional architectural change to the input event pipeline for built-in keyboards, or a beta regression? If intentional, what is the recommended alternative for developers?