How to make app appear in Input Monitoring permissions list (like Accessibility does automatically)?

Question

Created 1d

Replies 1

Boosts 0

Participants 3

My app needs both Accessibility and Input Monitoring permissions. Accessibility works as expected — calling AXIsProcessTrusted() automatically adds the app to System Settings > Privacy & Security > Accessibility, and the user just needs to toggle it on.

Input Monitoring doesn't behave the same way. I'm calling CGRequestListenEventAccess() and creating a CGEvent.tapCreate(.listenOnly), but the app doesn't reliably appear in the Input Monitoring list. The user opens the pane and sees nothing to enable.

What I've tried:

CGRequestListenEventAccess() — shows the system prompt once per install, but doesn't always add the app to the list
CGEvent.tapCreate(tap: .cgSessionEventTap, place: .headInsertEventTap, options: .listenOnly, ...) — returns nil before Accessibility is granted; after Accessibility is granted, the tap succeeds but the app still may not appear in the Input

Monitoring list 3. Calling both after Accessibility is confirmed, with a delay before opening the Settings pane

The flow:

User grants Accessibility (app appears automatically via AXIsProcessTrusted())
App creates a listen-only CGEventTap (succeeds)
App opens x-apple.systempreferences:com.apple.preference.security?Privacy_ListenEvent
User sees the Input Monitoring pane but the app is not listed

Environment: macOS 15 (Sequoia), signed and notarized app, correct bundle ID, Hardened Runtime with com.apple.security.device.audio-input-monitoring entitlement not set (not applicable — this is for audio, not HID).

Question: Is there an API equivalent to AXIsProcessTrusted() that reliably registers an app in the Input Monitoring list? Or is there a specific entitlement, Info.plist key, or sequence of calls required on macOS 14+/15 to ensure the app appears?

Answer 1

DTS Engineer OP

Apple

20h

My app needs both Accessibility and Input Monitoring permissions.

Why? Under the hood, "Accessibility" basically grants event posting and listening, while "Input Monitoring" only grants listening. However, I can't think of any situation where an app would actually NEED both, as "Accessibility" should already be providing everything Input Monitoring does.

Also, just so this is clear, the behavior here is intentional:

after Accessibility is granted, the tap succeeds

...as "Accessibility" specifically grants both "post" and "listen".

Question: Is there an API equivalent to AXIsProcessTrusted() that reliably registers an app in the Input Monitoring list?

Yes, though it's pretty obscure. The API is "IOHIDRequestAccess()". It's not documented in the class reference, but the session "Advances in macOS Security for WWDC 2019" covers it fairly well

As a side note:

Environment: macOS 15 (Sequoia), signed and notarized app, correct bundle ID, Hardened Runtime with com.apple.security.device.audio-input-monitoring entitlement not set (not applicable — this is for audio, not HID).

Actually, that entitlement is for "neither", because it's an LLM hallucination that doesn't exist. ~~I'll ask Quinn about adding it to his list~~

Actually, I'll add it to the list myself list.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware