Input Monitoring on Mac: what it allows, and why an app isn't in the list
Sooner or later a Mac app asks to "monitor input from your keyboard even when you're not using this app", and the honest reaction is alarm. Input Monitoring on a Mac is the permission that sits closest to a keylogger, and macOS deliberately makes it feel that way — yet it's also what a text expander or a key remapper genuinely needs. It's the permission that confuses people most, because it overlaps with Accessibility and nobody explains how. Here's what the toggle governs, when an app needs it, and why the fix for "my app isn't in the list" is almost never in System Settings.
What Input Monitoring on a Mac actually allows
Input Monitoring lets an app read keyboard, mouse and trackpad events system-wide — including events that land in other apps, while it sits in the background. Apple's own description is blunt: some apps can monitor your keyboard, mouse, or trackpad even when you're using other apps.
It arrived in macOS Catalina. Before that the capability lived inside Accessibility, which had quietly become an umbrella grant covering far too much; splitting it out gave people a separate switch for the read-my-keystrokes part. The list lives in System Settings → Privacy & Security → Input Monitoring (on Monterey and earlier: System Preferences → Security & Privacy → Privacy → Input Monitoring).
Legitimate reasons an app asks for it:
- Global hotkeys — a push-to-talk key has to be noticed while you type somewhere else.
- Text expansion — watching for
;addrmeans seeing what you type in every app. - Key remapping and macro tools — Karabiner-Elements and its relatives live here.
- Controller and input device utilities — anything translating a device's input into keys.
Input Monitoring on its own isn't a keylogger; it's the capability a keylogger would need. Which is exactly why the list is worth auditing occasionally.
Input Monitoring vs Accessibility vs Screen Recording
These three get confused constantly, because one app often appears in two of them. They authorise different things:
| Permission | What it authorises | Typical app |
|---|---|---|
| Input Monitoring | Read key and pointer events system-wide, in the background | Text expanders, remappers, push-to-talk |
| Accessibility | Act on the system — move and resize windows, click, send synthetic keystrokes | Window managers, automation tools |
| Screen Recording | See pixels — capture window or screen contents | Screenshot tools, window thumbnails |
The rule that trips up most people: Accessibility already includes Input Monitoring, but not the other way round. An app with Accessibility can read input without a second prompt — which is why a tool you granted Accessibility to may never appear in the Input Monitoring list at all. Reverse it and nothing works: an app with only Input Monitoring can read events but can't act, and macOS still reports it as untrusted for Accessibility.
It comes down to what the app asks for: an event tap opened in listen-only mode needs Input Monitoring, while a tap that can modify or swallow events needs Accessibility — that's the power to type on your behalf. So "this app has both" is normal for macro tools, and "this app has Accessibility but isn't in Input Monitoring" is normal too, not a bug to chase.
Why your app isn't in the Input Monitoring list
You can't pre-approve an app here. The list only contains apps that have already asked. So when something is missing, the question isn't how to add it — it's why it never asked. In order of likelihood:
- It has Accessibility, so it never needed to ask. See above. Check the Accessibility pane before assuming anything is broken.
- You haven't run the feature that triggers the request. Many apps request access lazily, the first time you use the hotkey or the expansion. Fire the feature and the prompt appears.
- A helper does the work, not the app you're looking for. Login items, agents and bundled helpers register under their own name. Look for a helper with a similar name rather than the app you launched.
- You launched it from the disk image. An app still running from a mounted
.dmgcan end up translocated, and its permission requests go nowhere useful. Drag it to Applications first, then open it from there. - It doesn't need Input Monitoring at all. Not every keyboard-driven app taps raw input — plenty register a system hotkey instead, which needs no permission of this kind.
If the app is listed but stale — greyed out, duplicated, or on but ignored — remove the entry with the − button and let the app ask again, rather than toggling it off and on. To make it ask from a clean slate, reset just that service:
tccutil reset ListenEvent com.example.appname
Leave off the bundle identifier and it resets Input Monitoring for every app on your Mac, which is rarely what you want.
The toggle is on and the app still can't see keys
Two things account for nearly all of these:
- It needs a real relaunch. macOS evaluates this permission when the process starts. The "Quit & Reopen" button in the alert often works, but if a modal window or a settings sheet is open it can silently fail — quit the app properly with ⌘Q and start it again.
- Something else already owns the key. If one specific shortcut does nothing while everything else works, that's a conflict, not a permission problem. Mac keyboard shortcut conflicts walks through finding what stole the combination.
And if the symptom is windows that won't move rather than keys that aren't seen, that's the Accessibility half of the story: window manager not working on Mac covers stale grants, the TCC database and the apps that ignore the API entirely.
Fewer permissions is a feature
It's worth asking what a keyboard-driven app requests before you install it — the answer varies a lot between apps that look similar from the outside. Ours are deliberately narrow. Let's Tile asks for Accessibility only: read where your window is, put it somewhere else, nothing more. Let's Switch asks for Accessibility, plus Screen Recording if you want live previews of each window — decline that one and the switcher still works with names and icons. Neither asks for your keystrokes, and neither collects telemetry.
That's the right way to read any permission prompt: not "is this app trustworthy" but "does this capability match what the app is for". A window tiler asking to monitor your typing is a question worth asking out loud.
Frequently asked questions
Is Input Monitoring the same as a keylogger? No — it's the permission a keylogger would require, and also what text expanders, remappers and push-to-talk need. What matters is whether the app has a reason for it.
Should I turn it off for apps I don't recognise? Yes. Switch it off, use the Mac normally, and see what breaks. Anything genuinely needed will ask again.
Why does an app appear in Accessibility but not Input Monitoring? Because Accessibility already covers reading input. The app never had to ask separately.
Do I have to restart my Mac after changing it? No — quitting and reopening the app is enough. A full restart only helps when the privacy database itself is confused.
Where is Input Monitoring in System Settings? System Settings → Privacy & Security → Input Monitoring. On macOS Monterey and earlier: System Preferences → Security & Privacy → Privacy → Input Monitoring.