Input Monitoring on macOS, explained
How the Input Monitoring permission actually works on a Mac — where it is stored, why apps need a relaunch after you grant it, why it vanishes after some updates, and what Secure Input does to it.
We have written before about what Input Monitoring and Accessibility grant and why you should be sceptical of apps that ask for them. This piece is the mechanical companion: how the permission works, why it behaves strangely, and how to fix it when it does.
Where the permission lives
macOS keeps privacy permissions in a system called TCC — Transparency, Consent and Control. Camera, microphone, Contacts, Full Disk Access, Screen Recording, Accessibility and Input Monitoring are all TCC services. Each has a list of apps that have been allowed or denied, and System Settings → Privacy & Security is a view onto those lists.
Internally, Input Monitoring is the service called ListenEvent. Accessibility, which also allows sending input and controlling other apps, is a separate service.
How an app ends up in the list
An app does not appear in the Input Monitoring list because it was installed. It appears the first time it tries to observe keyboard or mouse input system-wide. At that moment macOS blocks the attempt, shows a dialog pointing you to System Settings, and adds the app to the list with its toggle off.
Two consequences:
- An app that never asks is never listed. Its absence from the list is meaningful.
- Granting the permission does not always take effect immediately. Many apps set up their input listener once, at launch, and it failed. macOS often offers to quit and reopen the app for you; if it does not, quit and reopen it yourself.
Why the permission disappears after an update
TCC ties a permission to the app's code signature, not just its name. If an update is signed differently — a change of developer certificate, a build that was re-signed, or an unsigned build — macOS no longer considers it the same app. The old entry stays in the list, toggled on, and the new app is silently denied.
The fix is to remove the old entry with the minus button, then relaunch the app so it asks again. Toggling the existing entry off and on usually does not help, because it is attached to the old signature.
Resetting it cleanly
When the list has got into a confused state, you can reset one service from Terminal:
tccutil reset ListenEvent
That clears every app's Input Monitoring decision, and each will ask again the next time it needs it. You can limit it to one app by adding its bundle identifier:
tccutil reset ListenEvent com.example.someapp
The same command works for other services — Accessibility, ScreenCapture, Microphone — and it is far safer than editing the TCC database directly, which System Integrity Protection prevents anyway.
Secure Input: when a granted app still sees nothing
Even with Input Monitoring granted, an app does not receive every keystroke.
When a password field has focus, macOS turns on Secure Event Input, and system-wide listeners stop receiving key events until the field loses focus. Terminal has a Secure Keyboard Entry option that does the same for everything typed into it, and some password managers and remote-access tools switch it on as well.
This is why a text expander sometimes stops working in one app, or everywhere: something has turned Secure Input on and not turned it off. Quitting the app that enabled it restores normal behaviour. It is a deliberate protection, and it is also a reason not to assume "Input Monitoring granted" means "sees everything" — or, for that matter, "sees nothing sensitive". Many sensitive things are typed outside password fields.
Managed Macs
On a Mac managed by an employer or school, a configuration profile can pre-approve many TCC services. Input Monitoring and Screen Recording are treated more strictly: a profile can deny them, or allow a standard user to decide, but it cannot silently grant them. If a work Mac never shows you the toggle, a profile is the likely reason, and IT is the only fix.
Checking what you have granted
Once a quarter is reasonable:
- System Settings → Privacy & Security → Input Monitoring.
- For each app: do I still use it, and does its job need to see my typing?
- Remove entries for deleted apps and anything you cannot place.
Do the same for Accessibility, which is the more powerful of the two.
Apps that do not need it at all
Not every keyboard-related app needs to observe keystrokes. macOS can report that key-down and key-up events have occurred, as counts, without saying which key. Anything that only needs to react to the fact of typing can use that, and it requires no TCC permission at all.
ClackSmith is built that way. It plays keyboard sounds by comparing count-only key-down and key-up values for the current login session. It does not request Input Monitoring or Accessibility, so it never appears in either list, and it never receives key identities, key codes, characters or event contents.
The trade-off is visible: modifier-only presses and key autorepeat do not trigger sounds, and on some keyboards media keys may not either. What you get is bundled sound packs, packs built from your own audio files that stay on your Mac, a menu bar app with optional launch at login, and volume control through Shortcuts — with no keyboard history, clipboard access, advertising or analytics.