Mac menu bar app permissions: what to allow
A good Mac menu bar utility often needs a little trust. A bad one asks for broad access without a clear reason. Here is the practical test before you approve clipboard access, Input Monitoring, system audio recording, or anything else.
The short answer: approve a Mac app permission only when the feature cannot work without it, the app explains the exact scope, and you can turn the access off later. Deny broad permissions when the app is vague, account-first, cloud-first, or asking for access that does not match the job.
That rule matters most for menu bar utilities. They run quietly, start at login, and handle tiny parts of your workday: copied text, audio output, microphone state, screen time, display controls, screenshots, and local conversions. The category is useful because it is close to the system. The same closeness means you should read the permission prompt instead of clicking through it.
My bias is clear: I build TeenyApps, a set of native Mac utilities. The standard I use for my own apps is the same one I would use for anyone else's: the permission has to be tied to one visible feature, the data path should be local unless there is a real sync feature, and the limits should be easy to explain in one paragraph.
Quick permission guide
| Permission or access | When it is reasonable | When to say no |
|---|---|---|
| Clipboard monitoring | A clipboard manager saves searchable history, pins snippets, or previews copied files. | The app syncs clips by default, has no exclusions, or cannot explain where history is stored. |
| Input Monitoring | A global push-to-talk, hold-to-mute, or keyboard activity feature needs key-up and key-down events outside the active app. | A simple menu bar button asks for it before you use any keyboard feature. |
| Screen and system audio recording | An audio utility uses Core Audio taps to adjust app output, route sound, or capture system audio for a user-requested feature. | A non-audio app asks for it without a recording, sharing, or routing feature. |
| Microphone | The app records, processes, meters, or changes microphone input. | The app only claims to control speaker volume or play local sounds. |
| Accessibility | The app needs to inspect UI elements, automate clicks, follow active windows, or provide keyboard control that normal APIs cannot provide. | The feature is just a timer, calculator, encoder, color list, or static menu. |
| Network access | The feature clearly needs it: license activation, updates, cloud sync, or fetching a page you requested. | The app handles private local snippets but will not say what it sends out. |
01Start with the feature, not the prompt
Permission prompts are often scarier than the actual feature. They are also sometimes too broad. The only useful question is: what must the app touch to do the job?
A clipboard manager has to observe the system pasteboard. Apple exposes a change count on NSPasteboard, and apps can compare that count to know when the clipboard changed. That is how local clipboard history exists on macOS. The real privacy question is not "does it see the clipboard?" It has to. The real question is whether history stays local, whether sensitive apps can be excluded, and whether you can clear or cap the history.
A per-app audio mixer is different. Apple documents Core Audio taps as a way to capture outgoing audio from processes or groups of processes. That API is powerful enough that macOS puts it behind system audio recording permission. A responsible app should be plain about the tradeoff: it needs audio access to adjust app output, and it should not save or transmit audio unless recording is a feature you asked for.
02Clipboard managers deserve a privacy check
Clipboard history is useful because it remembers what you forgot. It is risky for the same reason. Meeting links, account numbers, API responses, addresses, customer snippets, tokens, one-time codes, and passwords can all touch the pasteboard.
The minimum standard for a Mac clipboard manager is local storage plus exclusions. TeenyClip, for example, is a local Mac clipboard utility. Its homepage says it keeps searchable history for text, images, files, and URLs. The source code polls NSPasteboard.general.changeCount, captures text, image, file URL, and URL pasteboard content, stores a bounded history, keeps pinned clips separate, and ignores clipboard changes from excluded apps while they are frontmost. It also keeps a short grace window after leaving a sensitive app so a delayed pasteboard change is still ignored.
That is the shape you want. You do not need every clipboard manager to work exactly that way, but you should expect three controls: pause or exclude apps, clear history, and limit retention. If those are missing, do not use the app for work snippets.
03Audio permissions need context
macOS now separates microphone-style permission from system audio recording, and the wording can still confuse normal users. A user sees "recording" and reasonably thinks "is this saving audio files?" Sometimes yes. Sometimes no.
TeenySound is a good example of why the prompt exists. It gives each audio-producing app its own volume slider, per-app mute, output routing, a mute-all hotkey, and saved volumes. Its source uses Core Audio taps, aggregate devices, and an IOProc playthrough engine to scale audio in real time. Its permission helper targets Apple's audio-only TCC service, and the app includes an NSAudioCaptureUsageDescription string for controlling individual app volume levels.
The honest user-facing answer is: per-app volume needs access to app output streams. That does not mean the app should store recordings. It does mean you should approve the permission only for an app whose whole purpose is audio control, recording, transcription, streaming, or routing.
04Input Monitoring is about keys outside the active app
Apple describes Input Monitoring as access to keyboard, mouse, or trackpad input even while you are using other apps. That is broad access. It can also be the correct access for a narrow job.
Use the distinction between toggle and hold. A normal global hotkey can often be registered without watching every key event. A hold-to-talk or hold-to-mute feature needs to know when the key is released while another app has focus. That is why some push-to-talk and push-to-mute modes need Input Monitoring while a simple click target does not.
The app should tell you which mode needs the permission. If the permission appears before you enable the feature that needs it, be skeptical.
05The five-question trust test
| Question | Good answer | Bad answer |
|---|---|---|
| Why does it need this permission? | One specific feature maps directly to the access. | "For the best experience" or another vague line. |
| What data leaves the Mac? | Nothing by default, or a named feature sends named data. | Telemetry, sync, or AI processing without detail. |
| Can I turn it off? | The app still works in a smaller mode, or explains what breaks. | The whole app fails even when only one optional feature needed access. |
| Can I exclude sensitive apps or data? | There is a pause, ignore-list, retention cap, or clear-history control. | The app collects every eligible item with no controls. |
| Does the developer say what the app does not do? | Clear limitations and no magical claims. | Big promises with no implementation detail. |
How to audit apps already installed
Open System Settings, Privacy and Security, then review the high-signal sections: Accessibility, Input Monitoring, Screen and System Audio Recording, Microphone, Camera, Full Disk Access, Files and Folders, and Automation. You do not need to panic-delete everything. You do need to match each approval to a feature you still use.
For menu bar utilities, I use a simple cleanup pass once a quarter. If I cannot remember why an app has a permission, I turn that permission off and see what breaks. If the app explains the missing permission clearly when I use the affected feature, fine. If it nags on launch without context, it gets uninstalled.
Also check launch-at-login apps. A one-off converter does not need to start every morning. A live mute, audio, clipboard, screen-time, display, stats, or shelf tool might. The permission decision and the login decision should be separate.
Where the TeenyApps fit
The TeenyApps bias is local, native, and narrow. TeenyClip is the clipboard member of that set, so it deserves a stricter privacy bar than a color picker or calculator. The deeper spoke is clipboard manager privacy on Mac. TeenySound is the audio member, so its system audio permission needs a better explanation than "trust us." The matching spoke is why Mac volume apps ask for system audio recording.
The wider hub articles cover adjacent decisions: local Mac utilities vs online tools is about keeping private transformations off random websites, and remote-work menu bar apps is about which controls belong in the menu bar during the day. This page is the missing privacy layer: when an always-on utility asks for access, decide based on the job it actually performs.
Sources checked
- TeenyApps product claims were checked against the live local homepages and source code for TeenyClip and TeenySound.
- TeenyClip homepage and TeenySound homepage.
- Apple Developer Documentation: NSPasteboard changeCount.
- Apple Developer Documentation: Capturing system audio with Core Audio taps.
- Apple Developer Documentation: NSAudioCaptureUsageDescription.
- Apple Support: Allow apps to use screen and audio recording.
- Apple Support: Control access to input monitoring on Mac.
Small Mac utilities should be easy to trust.
TeenyApps are native menu bar tools for clipboard history, sound, mic mute, screen time, displays, colors, screenshots, stats, shelves, and local utilities.