← Notes

Why typing-sound apps ask for frightening permissions

Input Monitoring and Accessibility are the two most powerful permissions on a Mac, and a surprising number of small utilities want them. Here is what each one actually grants and how to audit what you have already agreed to.

Install almost any keyboard utility, window manager, clipboard tool or text expander and macOS will show you a dialog asking for Accessibility or Input Monitoring. Most people click Allow, because the app does not work otherwise and the dialog does not explain much.

These two are not ordinary permissions. They are the most powerful things you can grant an application on a Mac, and it is worth understanding exactly what you are handing over.

What Input Monitoring grants

Permission to observe keyboard and mouse input across the whole system, not just inside the app you granted it to.

An app with Input Monitoring can see which keys you press while you are in any other application. That includes your password manager, your bank's login form, your private messages and anything else you type. It is, functionally, the capability a keylogger requires.

What Accessibility grants

Everything Input Monitoring grants, plus the ability to control other applications — read the contents of their windows, click their buttons, move and resize them, and send synthetic input.

It exists because screen readers and assistive software genuinely need it. It is also why an app with Accessibility access can read the text in a window you have open without you typing anything at all.

Accessibility is the stronger of the two by a wide margin.

Which apps have a legitimate need

Plenty do, and refusing on principle would cost you good software:

  • Window managers need Accessibility to move and resize other apps' windows. There is no alternative API.
  • Text expanders need to see what you typed to know when to replace it.
  • Clipboard managers usually need it to trigger on a hotkey and to read clipboard contents reliably.
  • Screen readers and assistive tools are the reason the permission exists.
  • Automation tools driving other applications.

The question is never "is this permission bad" but "does this app's job require it?"

A window manager moving windows: obviously yes. A text expander replacing what you type: yes. An app that plays a sound when a key goes down: no — it needs to know that a key was pressed, not which one.

That gap is where you should be sceptical, because the app gets far more capability than the feature requires, and you have no way to observe what it does with the surplus.

Auditing what you have already granted

Worth doing once, and it takes five minutes.

System Settings → Privacy & Security → Input Monitoring and → Accessibility.

Both lists show every app that has asked, with a toggle. Go through them and ask of each one: do I still use this, and does its job need this?

Things to look for:

  • Apps you installed for one task months ago and forgot.
  • Anything whose name you do not recognise. Helper processes have opaque names, but you should be able to trace each to an app you chose to install.
  • Apps that remain in the list after you deleted them. The entry persists; remove it.

Toggling one off is safe. The app will either keep working, which tells you it did not need it, or break in an obvious way, which tells you it did. There is no silent middle state.

While you are in there, Full Disk Access is worth the same treatment, and Screen Recording — which grants the ability to capture anything visible, including other people's messages in a video call.

How an app avoids needing it

macOS can report that a key-down or key-up event occurred — a count — without disclosing which key it was. For anything that only needs to react to the fact of a keystroke, that is sufficient, and it requires neither permission.

The visible trade-off is that the app cannot distinguish keys. It cannot play a different sound for the spacebar, and it does not see modifier-only presses or key autorepeat, because those are not distinguishable in a count-only stream.

That is a real limitation. It is also the entire reason the app never has the capability to record what you type.

What ClackSmith does

ClackSmith takes the count-only route. It does not request Input Monitoring or Accessibility permission — you will not see either dialog when you install it, and it will not appear in either list.

It reads count-only key-down and key-up values and never receives key identities, typed characters or keyboard event contents. It keeps no keyboard activity history, has no clipboard access, and carries no advertising or analytics. Modifier-only presses and key autorepeat do not trigger sounds, which follows directly from working with counts.

What you get is the ordinary set of features: bundled sound packs, your own packs built from audio files you own and kept on your Mac, a menu bar presence, optional launch at login, and volume control through Shortcuts.

It is a one-time purchase on the Mac App Store, which means it is sandboxed — worth knowing regardless of which app in this category you choose.

Keep reading