How to see which apps can access your camera, mic, and screen on Mac

Open System Settings and click Privacy & Security, and the honest answer is: it's all there, technically. It's just split across a dozen-plus separate lists, one per capability, that never add up to "here's what this app can do." Camera, Microphone, Screen & System Audio Recording, Accessibility, Input Monitoring, Full Disk Access, Automation, Location Services — each gets its own pane, its own toggles, and no awareness of the others. This guide goes through the panes that actually matter, how to tell what's recording right now instead of just what's allowed to, and the one thing most permission guides skip entirely: what happens to an app's access after you've already deleted the app.

Why there's no single "app permissions" screen on a Mac

Every Allow/Don't Allow prompt you've ever clicked through on a Mac is the same framework underneath. Apple calls it TCC, for Transparency, Consent, and Control. Each decision — this bundle ID, this capability, allowed or denied — gets logged into one of two SQLite databases: a per-user one at ~/Library/Application Support/com.apple.TCC/TCC.db, and a system-wide one at /Library/Application Support/com.apple.TCC/TCC.db for permissions that aren't tied to one account.

Neither database is meant to be opened directly, and it isn't something you can just go check yourself, either. System Integrity Protection blocks direct access to both folders, even with admin rights. Try ls on either path and you'll get "Operation not permitted" — full stop, no override. The only supported doors in are System Settings, one pane per capability, and a command-line tool called tccutil that can reset a decision but never set one. That's the real reason there's no combined view: the UI is one pane per capability because the system underneath is organized the same way, and nobody has shipped a by-app rollup for it on the Mac. iOS solved this years ago with an on-device App Privacy Report. macOS still hasn't shipped an equivalent.

Camera and Microphone: the two panes people check first

These are the simplest panes on the list. Go to Apple menu → System Settings → Privacy & Security → Camera (or Microphone), then flip each app's switch. Apple's own instructions for controlling camera access and controlling microphone access cover the toggle. A few things they don't spell out as plainly:

• Apple's own apps — FaceTime, Photo Booth — don't show up in either list. Apple's documentation is explicit that they get access automatically, with no separate prompt to grant.
• A website asking for camera or mic access inside Safari is a different permission entirely, controlled per site under Safari → Settings → Websites. If a video-call site keeps re-asking even though the app-level toggle is on, that's where to look.
• Not every app that shows up here got a moment of your full attention when it asked. If something you use for typing or file conversion is sitting in your Microphone list and you can't recall agreeing to that, it deserves a second look.

Screen & System Audio Recording, and why the name changed

This pane used to be called just Screen Recording. Current macOS labels it Screen & System Audio Recording, because the same toggle now also covers apps that capture your Mac's system audio output, not only what's on the display. The path is System Settings → Privacy & Security → Screen & System Audio Recording, and Apple's guide covers the toggle itself.

Since macOS Sequoia, this is also the one pane that nags you back: macOS re-asks for approval on a recurring, roughly monthly basis for any app already granted screen recording, a behavior carried into Tahoe. That's not a bug, and it's not you doing something wrong — Apple decided this particular permission is sensitive enough to make apps re-justify it on a schedule. When it happens, re-approving in the prompt (or toggling the app off and back on in this pane, then reopening it) clears it until the next cycle.

Screen recording access deserves more suspicion than Camera or Microphone, because of what it actually covers: anything rendered on your display, including a password typed into a form before you hit submit, a Slack message, a banking dashboard. Video-call apps, screenshot tools, and remote-support software need it for an obvious reason. A system cleaner or a battery monitor doesn't. If one asks, that's a real reason to say no.

Full Disk Access: the broadest grant on the list

If you only scrutinize one permission on this entire list, make it this one. Full Disk Access does exactly what the name says: an app holding it can read, and in most cases write, files across your whole startup disk, not just its own sandboxed folder or the files you've explicitly opened. That includes Mail's local message store, Messages attachments, Time Machine local backups, and other apps' protected data — the widest single grant macOS hands out short of running as root.

Apple deliberately makes this one impossible to grant silently. There's no prompt an app can trigger on its own and no way to pre-check the box during install. You go to System Settings → Privacy & Security → Full Disk Access yourself and add the app with the + button — Apple's Privacy & Security settings guide covers the exact path, though most apps that need it will walk you through the same steps the first time they hit a permission wall.

Legitimate reasons an app asks: backup software, disk-space or storage-analysis tools that need to see outside your home folder, security scanners, and some terminal emulators — iTerm2 asking for Full Disk Access to unlock features like reading other apps' shell history is a well-known example. What's actually worth questioning is a narrow, single-purpose utility — a PDF converter, a color picker, a menu-bar clock — asking for it with no stated reason. It might have one. It might also be asking for a lot more than the one job it advertises.

Accessibility and Input Monitoring: permissions that let an app act, not just look

Camera, Microphone, and Screen Recording are all about an app seeing or hearing something. Accessibility and Input Monitoring are about an app acting on your Mac, or watching how you act on it, which makes them a different category of decision.

Accessibility access lets an app observe and simulate mouse clicks, keystrokes, and window changes system-wide — genuinely necessary for window managers like Rectangle or Magnet, automation tools like Keyboard Maestro or BetterTouchTool, and real assistive technology, which is what the permission is named for. Input Monitoring is narrower but blunter: it lets an app read keyboard, mouse, or trackpad events even while a different app is in focus. That's exactly the capability a global-hotkey launcher needs, and exactly the capability a keylogger needs — Apple's own description of the permission is that "some apps can monitor your keyboard, mouse, or trackpad even when you're using other apps."

Neither permission is a red flag by itself. Both categories are full of legitimate, well-known tools. The combination that deserves a pause is an app you don't recognize, can't identify a real developer for, holding either one — or both. A signed, identifiable app requesting Accessibility to power a documented feature is routine. An app you can't place, asking for the ability to watch or simulate your input system-wide, is exactly the case to slow down on before you click Allow.

How to tell what's using your camera or mic right now

Everything above is about what's allowed. None of it tells you what's actually happening this second, and that's a different, more trustworthy signal, because it comes from the hardware layer, not a database row an app agreed to at install time.

Look at the menu bar. A green dot next to the Control Center icon means the camera is on right now; an orange dot means the microphone is; a purple dot means something is recording system audio. Apple documents the exact colors in its guide to what's in the Mac menu bar, and only one dot shows at a time — camera wins if both are active simultaneously. Open Control Center itself on macOS 13.3 or later and the field at the top names the specific app using the mic, camera, or system audio, instead of leaving you to guess which one it is.

This is the honest limit the rest of this guide can't get around: a permission being granted is not the same as an app using it right now. An app sitting in your Microphone list has been allowed to record; it may not have opened the mic in months. The dot is the only signal that separates "can" from "is," and unlike a permission list entry, it can't be faked by a background process sitting quietly — macOS lights it at the hardware level, the instant a capture session actually opens.

Revoking access: the Settings toggle, and the Terminal command that does more

For Camera, Microphone, and Screen & System Audio Recording, the toggle in each pane is the whole job. Flip it off and macOS stops that app cold until you turn it back on or the app asks again. For Full Disk Access, Accessibility, and Input Monitoring, do the same thing: select the app in its list and either flip the switch or click the − button to remove the row outright. If a switch won't budge, check for a lock icon at the bottom of the window — some panes need it unlocked with your password first.

There's a second option most Settings-only guides skip: tccutil, a command-line tool built into macOS specifically for resetting these decisions. The basic syntax:

tccutil reset SERVICE [bundle-id]

Concrete, verified examples:

tccutil reset Camera com.company.app
tccutil reset Microphone com.company.app
tccutil reset ScreenCapture com.company.app

Each clears that specific decision for that specific app. The app asks again — a real prompt, not a silent re-grant — the next time it needs that capability. Drop the bundle ID entirely and tccutil reset Camera on its own clears the decision for every app at once, which is blunt but occasionally exactly what you want. Apple's own tccutil man page shows the same pattern for wiping every permission a single app holds in one move: tccutil reset All com.apple.Terminal — swap in any bundle ID to reset all of that app's grants together.

To find a bundle ID for an app that's still installed, run:

mdls -name kMDItemCFBundleIdentifier /Applications/AppName.app

tccutil only ever resets a decision — Apple's own documentation is explicit that it can't grant one — and it doesn't touch anything outside the TCC databases. It's user-runnable for your own account's grants too; you don't need sudo to reset something you personally allowed. What you should never try is opening either TCC.db file directly with a database editor. System Integrity Protection blocks it, and even if you found a way around that, a malformed row is a good way to make every permission prompt on your Mac behave strangely until the database gets rebuilt.

The apps you already deleted can still hold permissions

Deleting an app doesn't touch its TCC entries, because the permission database is keyed to a bundle identifier and a decision, not to whether an .app bundle currently exists on disk. Drag an app straight to the Trash — see our guide on completely uninstalling a Mac app for everything else that leaves behind — and its rows in Camera, Full Disk Access, or wherever it had access simply stay put.

You can usually spot one: it's the entry with a generic or missing icon, because Launch Services can no longer resolve an app that isn't there anymore to draw an icon from. Select it and click the − button to remove the row, same as revoking any other app's access. If the button doesn't respond — a real, documented quirk in recent macOS versions — tccutil reset still works, and it doesn't require the app to exist on disk, only that you know its bundle ID and the service to clear. If you don't remember the bundle ID either, resetting the whole service (tccutil reset Camera, no bundle ID) clears it for everyone and just means every app you still use asks again next time. Annoying for an afternoon. Not risky.

None of this is dangerous to leave alone, either. A permission held by an app that no longer exists can't do anything with it — there's no process left to use the grant. It's clutter, not a live risk. Clear it if a messy list bothers you, and otherwise forget about it.

The faster path: a by-app view with SwoopByte Permissions

Everything above works, and none of it requires installing anything. It's a dozen-plus panes, a couple of Terminal commands, and enough clicking around to build the full picture for one app, let alone all of them. SwoopByte Permissions is a Mac app we're building that reads the same information into one screen — every app, every permission it can see, in plain language, organized by app instead of by pane. It's an auditor, never a blocker: it can't grant, block, or intercept a permission prompt, because that consumer API doesn't exist for any third-party app, ours included. It does name what's using your microphone right now, by process. The camera stays a device-level "in use" signal, the same limit described above, since no public API identifies which specific app has it open.

It also catches permission drift — an update quietly adding a new capability to an app you already trusted, something none of the Settings panes above will ever flag on their own. The audit and the revoke guidance are free, and stay free: reading the permission databases happens read-only, with no sudo, and the app makes zero network calls — nothing leaves your Mac. A one-time Pro license ($19.99, no subscription) adds change history, ongoing monitoring, and export, for anyone who wants more than a point-in-time read. It's still in development — join the waitlist to get it first.

FAQ

How do I see every permission one app has on my Mac?

There's no single built-in view. Check each Privacy & Security pane — Camera, Microphone, Screen & System Audio Recording, Accessibility, Input Monitoring, Full Disk Access — and look for the app in each list individually, since macOS doesn't roll them up by app on its own.

What's the difference between "Screen Recording" and "Screen & System Audio Recording"?

They're the same pane. Apple renamed it once the permission started covering apps that capture your Mac's system audio output as well as the screen, not just the display.

Does a green or orange dot always mean my camera or mic is actually on?

Yes. The dots reflect an active hardware session, lit by macOS itself, not a setting an app can fake. A permission listed as allowed only means the app is capable of turning the camera or mic on — the dot is the only signal that tells you it's happening right now.

Can I edit TCC.db directly to fix a stuck permission?

No. Both TCC databases are protected by System Integrity Protection, and even an admin account gets "Operation not permitted" trying to just list the folder they live in. Use System Settings or tccutil — those are the only supported ways to change a permission decision.

Why does an app I already deleted still show up in Full Disk Access?

Permission grants are stored by bundle identifier, not tied to whether the app still exists on disk. Removing the app doesn't remove its TCC entry — select it in the list and click the − button, or run tccutil reset for that service and bundle ID, to clear it.

Which apps actually need Full Disk Access?

Backup software, storage and disk-cleanup tools that look outside your home folder, security scanners, and some terminal emulators are the common, legitimate cases. A narrow single-purpose utility asking for it with no stated reason is worth questioning before you say yes.

Related guides