Mac Keeps Asking for Screen Recording Permission: Real Fixes

You open Zoom, click Share Screen, and macOS puts up the same dialog it put up last month asking whether Zoom may record your screen. You already said yes. You go to System Settings, and there it is: Zoom, in the Screen & System Audio Recording list, toggled on. Nothing is broken. And yet you were asked again.

A week later something different happens. Your backup tool cannot read your Mail folder. You check Full Disk Access and the app is listed, toggled on, exactly as it should be. But the app behaves as though it has no permission at all. This is not the same problem, even though it produces the same feeling.

These two situations get treated as one thing across most of the advice you will find, and that is why so much of that advice fails. The first is deliberate. Apple built a periodic re-confirmation into the screen capture permission and there is no switch to turn it off. The second is a genuine fault with a specific, findable cause, and it almost always comes down to one thing: macOS no longer believes the app on disk is the same app you granted permission to.

This article separates the two, explains the subsystem underneath both of them, and gives you the correct fix for each. It also explains why the single most common piece of advice on this topic, which is to change file permissions with chmod or to run some kind of permission repair, has nothing whatsoever to do with the system involved. Everything demonstrated below was tested on a Mac running macOS 26.5.2, build 25F84, with System Integrity Protection enabled.

Key Takeaways

• Two different problems wear the same face — a scheduled re-prompt for screen capture is by design and cannot be disabled, while a granted-but-non-functional permission is a real fault with a real cause.
• TCC binds permission to an app's code-signing identity, not its path — that is why a permission silently stops working after an update, a move, or when two copies of the same app exist on disk.
• tccutil reset is the only command Apple ships — there is no way to grant a permission from Terminal, and running reset without a bundle identifier wipes that permission for every app on the Mac.
• The privacy databases are unreadable even to ls — on a tested Mac with SIP enabled, listing either TCC directory returns Operation not permitted, which is the clearest possible proof that this is not ordinary file permissions.
• Apple does not publish the service-name list — names like ScreenCapture and SystemPolicyAllFiles are community knowledge, and any guide presenting them as official documentation is guessing.

What TCC Is and What It Is Not

The subsystem that decides whether an app may record your screen, read your Mail folder, use the microphone, or control other apps is called TCC. The initials stand for Transparency, Consent and Control. It is the thing that produces every "App would like to access…" dialog you have ever clicked through, and it is the thing that populates every list in System Settings under Privacy & Security.

Apple's man page for the one command-line tool in this area describes it in a single sentence. Under NAME it reads "tccutil – manage the privacy database", and the DESCRIPTION expands that to: "The tccutil command manages the privacy database, which stores decisions the user has made about whether apps may access personal data."

Read that carefully, because the wording is precise and it tells you the shape of the whole system. TCC stores decisions. It is a record of consent. It is not a description of a file, it is a description of a relationship between an application and a category of protected data.

The Privacy Database Is Not the File System

This is the misconception that wastes more time than any other, so it is worth dispatching immediately.

Traditional Unix file permissions are attributes stored on the file itself: an owner, a group, and read/write/execute bits, changed with chmod and chown. They answer the question "which user accounts may touch this file?"

TCC answers a completely different question: "which application has the user consented to let read this category of data?" The user account is not the subject. The application is. Howard Oakley of The Eclectic Light Company put the distinction well in his November 2025 explainer on permissions and privacy, writing that "privacy protection operates outside of file attributes, using a rule-based system applied to each app."

The practical consequence is absolute. Your user account already owns ~/Library/Mail, and the POSIX bits already say you may read it. That is precisely why a terminal command run as you can read it and a GUI app run as you cannot: the file permissions were never the obstacle. TCC was.

So no amount of chmod will fix a TCC problem. Neither will any "repair permissions" routine, a concept that dates back to the pre-APFS era, applied to the receipts database, and which Apple removed from Disk Utility years ago. Running sudo chmod -R 755 across your home folder in pursuit of a screen recording prompt will not help, and it can damage your Library folder. Do not do it.

The Databases You Cannot Read, Even to List Them

There are two TCC databases. The per-user one lives under ~/Library/Application Support/com.apple.TCC/ and holds decisions that apply to your account. The system-wide one lives under /Library/Application Support/com.apple.TCC/ and holds decisions that apply machine-wide, including the ones an administrator or an MDM profile can set.

Here is the demonstration that settles the argument. On the test Mac, with SIP enabled, both of these were attempted:

ls ~/Library/Application\ Support/com.apple.TCC/
ls /Library/Application\ Support/com.apple.TCC/

Both returned Operation not permitted. Not "permission denied", which is what a POSIX failure looks like, but the response the kernel gives when System Integrity Protection blocks the access outright. SIP was confirmed active: csrutil status returned System Integrity Protection status: enabled.

You cannot list these directories, read the databases inside them, or edit them. If a guide tells you to open TCC.db in a SQLite browser and insert a row, it is describing a machine with SIP disabled, and disabling SIP to work around a permissions prompt trades away a large part of your Mac's defensive architecture to solve a dialog box. This article will not tell you how to do that.

What you can do is grant permission through the System Settings interface, reset a decision with tccutil, or have an MDM profile write a decision on your behalf. Those are the three doors. There is no fourth.

Why This Design Exists

If TCC decisions lived in an ordinary editable file, any app with write access to your home folder could silently grant itself screen recording, camera access, and the run of your Mail folder. The protection would be worthless. So Apple put the decisions behind SIP, made the only supported write path a user interaction with a system-drawn dialog, and gave the command-line tool exactly one verb: reset.

That is a coherent design and, from the point of view of someone fixing a broken permission at 11pm, a very small toolbox. Most of this article is about using it well. For the broader context on how macOS layers Gatekeeper, notarisation, SIP, and TCC together, our complete guide to macOS Tahoe security and privacy covers the surrounding architecture.

The Two Different Problems

Now to the separation that the rest of this article depends on.

Problem One: The Deliberate Re-Prompt

During the macOS 15 Sequoia beta cycle in 2024, Apple introduced periodic re-confirmation for screen and audio capture. Any app that captures your screen would be asked to re-confirm on a schedule, with no way to opt out.

The initial beta behaviour was weekly, and it also re-prompted after every restart. That drew substantial public criticism. MacRumors reported in August 2024 that "popups for screen recording app permissions have been showing weekly up throughout the beta testing process, but Apple has tweaked the frequency in response to user feedback," and that the beta had moved to monthly reauthorisation. 9to5Mac and iDownloadBlog reported the same change from the same beta. The per-restart prompt was dropped at the same time. The dialog offers an "Allow For One Month" button and an option to open System Settings, and MacRumors noted then that "it does not appear that there is a way for users to permanently give screen recording access to recording functionality, but a monthly popup is at least more convenient than a weekly popup."

Now the honest part. I could not verify the current cadence in the macOS 26 generation from any authoritative source. Apple's own support page for this pane, "Allow apps to use screen and audio recording" in the macOS Tahoe 26 Mac User Guide, describes how to open the pane and how to answer the dialog, and says nothing at all about periodic re-approval. The secondary sources that discuss macOS 26 contradict each other, some describing a weekly re-prompt and some a monthly one, and none of them cite anything.

So here is what can be said with confidence and what cannot. Confirmed: the periodic re-prompt was introduced in the Sequoia cycle, applies to screen and system audio capture, offers a one-month allowance, and has no user-facing off switch. Confirmed: Apple's current support documentation for the pane does not mention it at all. Not confirmed: the exact interval in the macOS 26 generation. If your Mac re-prompts roughly monthly, that matches what Apple shipped in Sequoia. If it prompts far more often, read the fault diagnosis below, because frequent re-prompting is a different problem.

The most useful thing to know about Problem One is that it is not a fault and there is nothing to fix. Clicking Allow takes one second, and the dialog itself is the re-confirmation, so you do not need to re-toggle anything in System Settings. Every guide that tells you to reset, reinstall, or edit something in response to a monthly prompt is selling a cure for a healthy patient.

There is one developer-side exception. Apple has an entitlement named com.apple.developer.persistent-content-capture that suppresses the recurring prompt, and Michael Tsai's blog collected the developer discussion around it in August 2024. It is a managed capability aimed at remote-control and VNC-style applications: developers must apply to Apple and be granted it. You cannot enable it as a user. It only explains why a small number of remote-access apps never nag you.

Problem Two: The Grant That Does Not Stick

This one is a genuine fault. It looks like an app listed in the pane and toggled on that behaves as though it has no permission; an app that disappears from the pane after an update; a permission that works until you quit and relaunch; two entries with the same app name; a tool that never appears in the pane even after you add it with +; or a prompt on every single launch rather than once a month.

All of these have causes, and most share a single cause. That is the next major section.

One thing that is not on this list, despite looking like it belongs: a Mac that repeatedly asks for your login keychain password. That is the keychain subsystem, not TCC, and nothing in this article will fix it. If that is your symptom, the login keychain password prompt fix covers the right ground.

Which Problem Do You Have

Symptom	Which problem	What to do
Screen capture prompt roughly once a month, app works after clicking Allow	By design	Click Allow. Nothing is wrong.
Prompt on every single launch	Fault	Signing identity or duplicate-copy problem. See below.
Toggled on in the pane, app still cannot do the thing	Fault	Stale entry bound to an old identity. Clean re-grant.
App vanished from the pane after updating	Fault	Signature changed. Re-grant.
Two entries with the same name in the pane	Fault	Two copies on disk. Find and remove one.
CLI tool works but never appears in the pane	Known macOS 26.1 bug	See the command-line section.
Prompt appears, you click Allow, nothing happens	Fault	Often the app was never quit fully. Clean re-grant.
Toggle is greyed out with a profile note	Managed Mac	Contact whoever manages the device.
Non-capture permission re-prompting monthly	Fault	Only screen capture has a scheduled re-prompt.

Where Each Permission Lives in the macOS 26 Generation

All of these panes live under the same root. Open System Settings, click Privacy & Security in the sidebar, then choose the category. The categories relevant to this article:

• Screen & System Audio Recording. Renamed in the macOS 26 generation; it was Screen Recording before. Apple's description is one line: "Allow apps to record your screen and audio, or just your audio. The listed apps have access."
• Full Disk Access. Protected user data across the whole system: Mail, Messages, Safari data, Time Machine backups, and other apps' container folders.
• Accessibility. The ability to control your Mac: move the pointer, click, read window contents, drive other applications' interfaces.
• Automation. The right for one specific app to send Apple events to another specific app. It is the only pane organised as pairs rather than a flat list.
• Files and Folders. Fine-grained folder access: Desktop, Documents, Downloads, removable and network volumes. An app with Full Disk Access needs no entries here.
• Input Monitoring. Lets an app see keystrokes even when it is not frontmost.
• Camera and Microphone. Exactly what they sound like. If your microphone specifically is misbehaving, the input-permission chain has its own quirks, covered in the guide to fixing a Mac microphone that stopped working on macOS Tahoe 26.5.
• Local Network. Newer, and a common source of confusion because a blocked local-network permission produces symptoms that look nothing like a privacy problem. A printer that has stopped responding is the classic example, walked through in the AirPrint and local network privacy fix.

Two structural facts that matter later. The list you see is a rendering of the database, and the macOS 26.1 bug described below proved the rendering can be wrong while the database is right. And removing an entry with the - button deletes the decision rather than denying the app, so the next time the app asks you get a fresh prompt. That distinction is the basis of the clean re-grant sequence.

Why a Granted Permission Stops Working

Here is the mechanism. If you understand this one thing, most of the confusing behaviour in this area becomes predictable.

TCC Binds to Code-Signing Identity, Not to a Path or a Name

When you grant an app permission, macOS does not record "the file at /Applications/Foo.app may record the screen." It records a decision tied to the app's code-signing identity: its identifier, and the cryptographic requirement that describes who signed it. Apple's technote TN3127, "Inside Code Signing: Requirements," is the reference for how those requirements are constructed.

The consequence is the thing nobody tells you: if the signing identity changes, macOS treats the app as a different application that has never been granted anything. The old entry stays in the pane, looking granted, describing an app that no longer exists in the form the database remembers. You see a toggle that is on. The system sees a stranger.

You can inspect an app's identity yourself. On the test Mac:

codesign -dv --verbose=2 /System/Applications/Utilities/Terminal.app

The output includes an Identifier line, which is the bundle identifier the system uses (com.apple.Terminal for Terminal), a chain of Authority lines naming the certificates that signed it, and a TeamIdentifier line. For Apple's own bundled apps, TeamIdentifier reads not set, because Apple signs its system software through a different authority chain than third-party developers use. For a third-party app you should see a ten-character team identifier and an authority chain including a Developer ID certificate.

That team identifier is the stable anchor. An app signed ad hoc, with no team identifier, is identified by its code hash alone, and a code hash changes with every single build. An app signed with a Developer ID has a stable team identity that survives updates. This is why some apps re-prompt after every update and most do not.

Now the specific cases.

Case One: The App Updated and Was Signed Differently

The app shipped a new version. The new build was signed with a different certificate, or the developer moved from ad-hoc signing to Developer ID, or the reverse, or their certificate expired and they re-signed with a new one.

How to spot it: the timing lines up exactly with an update, and the app either vanished from the pane or gained a second entry.

Fix: remove the stale entry and re-grant. There is nothing else to do; the app is genuinely a new app as far as TCC is concerned.

Case Two: Two Copies of the Same App on Disk

This is the most common cause of the "toggled on but does not work" symptom, and the easiest to miss.

You downloaded an app, ran it once from ~/Downloads, granted permission, then later dragged it to /Applications. Or Homebrew Cask installed a copy while you already had one. Or you keep a release build in /Applications and a beta in ~/Applications. The pane shows one row with the app's name and icon; it does not tell you which copy that row refers to. You are looking at a grant for the copy in ~/Downloads while launching the copy in /Applications.

How to spot it: search for every copy on disk.

mdfind "kMDItemKind == 'Application'" -name "AppName"

Or, for a sweep that includes copies Spotlight may not have indexed:

find /Applications ~/Applications ~/Downloads ~/Desktop -maxdepth 3 -name "AppName.app" 2>/dev/null

If more than one path comes back, that is your answer.

Fix: delete the copies you do not want, keep exactly one, then do a clean re-grant on the survivor. Do not skip the deletion; leaving a second copy on disk means you will be back here in a month.

Case Three: The App Was Moved After Being Granted

Related to case two but distinct. There is only one copy, but it moved. Some apps survive this cleanly and some do not, depending on how their signing requirement is written and whether an embedded helper's path is baked into the parent's structure.

How to spot it: the app was working, you reorganised your Applications folder or restored from a migration, and it broke.

Fix: clean re-grant at the new location. If it was moved into a subfolder inside /Applications, try moving it back to the top level first; a few apps with self-updating machinery behave badly in subfolders.

Case Four: An Incomplete Update Invalidated the Signature

An update was interrupted, a sync tool touched the bundle, an antivirus product quarantined and restored a file inside it, or a backup restore reconstructed the bundle imperfectly. The signature no longer validates.

How to spot it:

codesign --verify --deep --strict --verbose=2 /Applications/AppName.app

A healthy bundle produces a short report ending with a statement that the app is valid on disk and satisfies its designated requirement. A damaged one names the specific file that fails. If you see a failure here, no amount of permission fiddling will help, because macOS will not trust the bundle at all.

Fix: reinstall from the developer's original download. This is one of the few cases where "reinstall the app" is genuinely the correct answer rather than a shrug. A related and more visible failure mode of the same underlying damage is the "app is damaged and can't be opened" dialog, which we cover in detail in the Gatekeeper and quarantine fix guide.

Case Five: Sparkle-Style Self-Updaters That Replace Their Own Bundle

Many Mac apps distributed outside the App Store update themselves using the Sparkle framework or something like it, downloading a new version and swapping their own bundle in place while running.

When this works properly, the new bundle carries the same team identifier and TCC continues to recognise it. When it does not, because the update was signed differently, or the swap left a partially-written bundle, or the app replaced itself at a slightly different path, you get a re-prompt or a silent failure the next time you use a protected feature.

How to spot it: the app updates itself outside the App Store, and permission problems cluster around the moment it updates.

Fix: clean re-grant after the update completes. If it happens on every update, the developer's signing setup is the problem and worth reporting to them, because it is fixable on their end.

The General Diagnostic

Faced with any "granted but not working" case, ask three questions in order: how many copies of this app exist on disk (mdfind), does the bundle verify (codesign --verify), and did it break immediately after an update? Those three answers point at one of the five cases above nearly every time.

The Terminal Tools: What tccutil Can and Cannot Do

There is exactly one command-line tool for this subsystem, and its capabilities are much narrower than most guides imply.

reset Is the Only Command

Run tccutil with no arguments on macOS 26.5.2 and it prints its usage string:

tccutil: Usage: tccutil reset SERVICE [BUNDLE_ID]

That is the whole interface. Apple's man page is explicit that "one command is currently supported", and describes it as:

reset Reset all decisions for the specified service, causing apps to prompt again the next time they access the service. If a bundle identifier is specified, the service will be reset for that bundle only.

Apple's own examples in the man page are tccutil reset AddressBook and tccutil reset All com.apple.Terminal.

Draw the consequence that most guides skip: there is no grant command. You cannot approve a permission from Terminal. reset forgets a decision so the app will ask again; it does not say yes on your behalf. The only ways to say yes are the System Settings interface and an MDM configuration profile. If you find a guide claiming a tccutil incantation that grants Full Disk Access, it is wrong.

The Bundle ID Warning That Matters Most

This is the practical core of the whole Terminal section, so it gets its own space.

# DANGEROUS - resets screen recording for EVERY app on the Mac
tccutil reset ScreenCapture

# Correct - resets it for one app only
tccutil reset ScreenCapture com.example.appname

The bundle identifier is optional in the syntax and mandatory in practice. Omit it and you have told macOS to forget every screen recording decision on the machine. Zoom, Slack, Discord, Teams, your screenshot tool, your recording software, your remote support client: all of them will prompt you the next time you use them. Nothing is permanently broken, but you have created an afternoon of dialog boxes for yourself in pursuit of fixing one app.

tccutil reset All with no bundle identifier is worse still, forgetting every decision for every service for every app. If a guide tells you to run that as a first step, close the guide.

Always append the bundle identifier. Every time, without exception.

The Argument Validation Order, and Why It Can Hide a Typo

This was tested directly, and the behaviour affects how you read errors. tccutil validates the bundle identifier before the service name. Give it a bogus service and a bogus bundle ID together:

tccutil reset ZZZNotAService com.example.nonexistent.zzz

and it returns:

tccutil: No such bundle identifier "com.example.nonexistent.zzz": The operation couldn't be completed. (OSStatus error -10814.)

It complains about the bundle, not about the obviously invalid service name. Give it a bogus service with no bundle ID at all:

tccutil reset ZZZNotAService

and it returns:

tccutil: Failed to reset ZZZNotAService

The practical consequence: a typo in the bundle identifier always gives you a clear, specific error, which is good. But a typo in the service name can be masked when the bundle identifier is also wrong, because the tool never gets far enough to complain about it. If you get the -10814 error, fix the bundle identifier first, then run the command again and see whether the service name was also wrong.

The corollary is: verify the bundle identifier before you build the command.

How to Find an App's Bundle Identifier

Two reliable methods. The first was verified on the test Mac, where osascript -e 'id of app "Terminal"' returned com.apple.Terminal and osascript -e 'id of app "Safari"' returned com.apple.Safari:

osascript -e 'id of app "AppName"'

Substitute the app's name as it appears in Finder. This is the quickest method, and it is the one Howard Oakley's readers surfaced in the comments on his overview of privacy protection, which he acknowledged.

The second method reads the bundle directly, which is useful when the app is not in a standard location or AppleScript cannot resolve the name:

defaults read /Applications/AppName.app/Contents/Info.plist CFBundleIdentifier

Or use the code-signing view, which shows you the signing authority at the same time, and read its Identifier= line:

codesign -dv --verbose=2 /Applications/AppName.app

Use whichever you like, but use one of them. Do not guess the identifier from the app's name. Reverse-DNS naming is a convention, not a rule, and plenty of apps have identifiers that bear no resemblance to what you would guess.

Service Names Are Community Knowledge, Not Apple Documentation

Here is where honesty matters more than completeness.

Apple does not publish the list of service names that tccutil reset accepts. The man page gives exactly two by example: AddressBook and All. That is the entirety of Apple's documentation on the subject.

The names in circulation come from the community. Howard Oakley published a list in his March 2025 overview of privacy protection that includes, among others:

Accessibility, AddressBook, All, AppleEvents, AudioCapture, BluetoothAlways, Calendar, Camera, ContactsFull, ContactsLimited, DeveloperTool, FocusStatus, MediaLibrary, Microphone, Motion, Photos, PostEvent, Reminders, RemoteDesktop, ScreenCapture, SpeechRecognition, SystemPolicyAllFiles, SystemPolicyDesktopFolder, SystemPolicyDocumentsFolder, SystemPolicyDownloadsFolder, SystemPolicyNetworkVolumes, SystemPolicyRemovableVolumes.

Two of those map to the panes this article is most concerned with: ScreenCapture for Screen & System Audio Recording, and SystemPolicyAllFiles for Full Disk Access.

I did not brute-force-test these names on the test Mac, deliberately. A tccutil reset that succeeds wipes the machine's real permissions, so the only way to confirm a name works is to destroy the thing you were trying to preserve, and testing the ones that fail tells you nothing. The list above is well-sourced community knowledge that matches what practitioners use in the field. It is not Apple documentation, and I would rather say so than present it as authoritative.

Two things follow. If a tccutil reset appears to do nothing, consider that the service name may be wrong before concluding the system is broken. And prefer the System Settings route when you can, because the pane never has a spelling problem.

Command-Line Binaries and Helper Tools

This is the area where the model of "one app, one entry in a list" breaks down hardest, and where a well-documented macOS 26 bug made things considerably worse for a while.

A Plain Executable Has No Bundle Identifier

An .app is a bundle: a directory with a defined structure containing an Info.plist that declares, among other things, a CFBundleIdentifier. A compiled binary sitting in /usr/local/bin has none of that. It is just a Mach-O executable.

TCC's model is built around bundles. A plain executable can still be granted permission, but it has no bundle identifier to key on, which is why it may not appear in the pane the way an app does, and why tccutil reset Service bundle.id has nothing to target for it.

The macOS 26.1 Display Bug, and What It Taught Everyone

In late 2025 a cluster of Apple Developer Forums threads reported the same thing across different permissions. It is worth walking through, because Apple's own engineers confirmed the diagnosis and the outcome tells you something durable about how the pane relates to the database.

Thread 807898, "Issue: Plain Executables Do Not Appear Under 'Screen & System Audio Recording' on macOS 26.1 (Tahoe)", reported that a plain executable requesting screen recording still got the normal prompt, still captured the screen correctly once granted, but never appeared in the System Settings list. The poster's summary: "macOS 26.1 (Tahoe) appears to require app bundles for an item to be shown in the Screen Recording privacy UI. Plain executables: still request and receive permission, still function correctly after permission is granted, but do not appear in the System Settings list." The same code packaged as an .app bundle appeared normally. Quinn "The Eskimo!", a DTS engineer at Apple, replied confirming it: "IMO this is a bug and I encourage you to file it as such."

Thread 807323, "Background Unix executable not appearing in Screen Recording permissions UI (macOS Tahoe 26.1)", reported the same symptom from another angle. A background Unix executable calling CGRequestScreenCaptureAccess() worked on 26.0.1 and stopped appearing in the UI on 26.1. The poster noted that manually adding the executable with the + button "grants permission internally, but the executable still doesn't show in the UI", so users "cannot verify or revoke permissions." That thread drew no Apple response, only corroboration from another developer. Thread 809549 raised the same problem for Full Disk Access, reporting that command-line binaries "fail to appear under the FDA settings, even after selection"; Quinn redirected it to the existing consolidated thread and a moderator locked it.

That consolidated thread, 806187, is where the resolution lives. The key finding: the permissions were being recorded correctly the whole time. The database was right; the list was wrong. As one participant put it, "CLI apps can have full disk access or other permissions, but you cannot see it in the list." A "Background Security Improvements" feature added in 26.1 had changed the settings interface to show only bundled applications.

The interim workaround was to "drag the binary from Finder to the full disk access list in System Settings window. The permission will be given, but it won't show in the list." The durable recommendation came from Kevin Elliott, another DTS engineer: "The better solution is to embed that tool inside an app bundle. I don't mean 'make your command-line tool act like an app', I mean 'take your command-line tool and stick it inside an app bundle, then use it exactly the way you were using it before'."

Multiple participants confirmed the display bug was fixed in the macOS 26.3 beta, and someone on thread 807898 reported that a parallel Accessibility version of the problem, present in 26.1 and the 26.2 beta, was resolved in 26.3 as well.

Why this matters to you even if you are past 26.1: the pane is a view of the database, and views can lie. If an app or tool demonstrably has a permission but does not appear in the list, do not assume the permission is missing. Test the behaviour before you start resetting things.

Why an App Launched From Terminal Inherits Terminal's Permissions

This trips up developers constantly, and once you know the rule it stops being mysterious.

TCC does not simply ask "which binary is making this request?" It walks what Howard Oakley describes as "an attribution chain that traces up through the call chain to an app that is responsible for the privacy settings to be applied." The system looks for the responsible process, which is usually the app the user launched, not the deepest process in the chain.

So when you run a program from Terminal, Terminal is typically the responsible process. Your program's screen capture request becomes Terminal's screen capture request. If Terminal has the permission, your program works; if it does not, the prompt names Terminal rather than your program. This is exactly what the poster on thread 807898 observed: when launched from another app such as VS Code or Terminal, "the parent app appears in the list instead, not the executable itself."

Three consequences in daily use. Granting your terminal emulator a permission means every tool you run in it inherits that grant, which is convenient and also a real privilege expansion worth thinking about before doing casually. The same script behaves differently launched from Terminal, from a LaunchAgent, and from a double-clicked app wrapper, because the responsible process differs in each case. And switching terminal emulators means starting over, since iTerm2, Ghostty, Warp, Kitty, and Terminal.app are each a separate identity.

Helper Tools, XPC Services, and Login Items

A modern Mac app is frequently several executables: the main app, possibly a privileged helper under /Library/PrivilegedHelperTools, possibly XPC services embedded in the bundle, possibly a launch agent that runs at login.

Embedded XPC services inside a properly signed bundle generally operate under the parent app's attribution, because the chain resolves to the app. Separately installed helpers and launch daemons frequently do not: they run outside the app's process tree with their own identity, and need their own grant. This is why some apps ask you to approve a permission twice, once for the app and once for its helper, and why a helper installed as root may need an entry in the system database rather than your per-user one.

If an app half works, where the interface responds but a background function silently fails, a helper without permission is a strong suspect. The app's own support documentation is the fastest route to knowing which helper needs what, because you cannot determine it from the pane.

Screen Recording Specifically

The pane is System Settings → Privacy & Security → Screen & System Audio Recording. Apple's description, verbatim: "Allow apps to record your screen and audio, or just your audio. The listed apps have access."

Points specific to this permission:

It is the only permission with a scheduled re-prompt. No other TCC category re-asks on a timer. If your camera permission or your Full Disk Access is prompting you monthly, that is not the designed behaviour and you have a fault.

Toggling it usually requires the app to restart. Many apps read the capture capability once at launch. Turn the toggle on while the app is running and it may not notice until relaunched. This alone accounts for a lot of "I enabled it and nothing happened" reports.

System audio and screen are grouped but not identical. The pane covers both. Some apps request only audio. If an app captures your screen fine but records silence, look at whether it requested system audio capture at all, and check the app's own audio device settings, because a missing virtual audio device is a completely separate problem from a TCC one. The complete guide to screen recording on Mac walks through the audio side in detail.

A real-world hard case, honestly reported. A Microsoft Q&A thread documents Teams for Mac on macOS Tahoe 26.4, build 25E246, looping on the screen sharing permission prompt. The reporting administrator verified everything a person can verify: a PPPC profile deployed by MDM targeting com.microsoft.teams2 with a correct code requirement, the system-level TCC record showing auth_value=2 for kTCCServiceScreenCapture, the user-level record showing the same, and System Settings showing Teams toggled on with the note that the setting had been configured by a profile. They had cleared caches, removed the legacy com.microsoft.teams identifier, reinstalled through MDM, killed and relaunched processes, and rebooted.

The answers offered were the standard remediation: "fully quit Teams, remove and re-add or re-toggle the Teams entry in Screen Recording, then restart Teams and re-attempt sharing so macOS can re-prompt and re-bind the permission," and failing that, escalate to Microsoft support with client logs. Three weeks later the reporter said no working solution had been provided and they were using the web app instead. Sometimes the permission really is granted at every layer and an application-side bug is at fault. Knowing when to stop is part of the skill.

Full Disk Access Specifically

Full Disk Access is the broadest permission in the system. It is what backup tools, migration utilities, security software, and terminal emulators used for administration need.

It is not the same as the Files and Folders entries. Files and Folders grants a specific folder. Full Disk Access grants protected data across the machine: Mail, Messages, Safari browsing data, Time Machine backups, and other applications' container directories. An app with Full Disk Access needs nothing in Files and Folders.

It almost always requires an app restart. More than any other permission, Full Disk Access tends to be evaluated at process start. Grant it, then quit and relaunch the app. Many apps show a dialog telling you to do exactly this; believe them.

It cannot be requested by a prompt. An app cannot pop a dialog that grants Full Disk Access on approval; it can only send you to the pane. That is why apps needing it show instructions rather than a system dialog, and why "I clicked Allow and it still does not work" is a common report: there was no Allow to click.

For a terminal emulator, the grant is broad. Giving Terminal or iTerm2 Full Disk Access means every command you run in it has that reach, through the attribution chain described earlier. That is often exactly what an administrator wants. Understand that it is what you are doing.

Command-line tools were affected by the 26.1 display bug described above, with the fix landing in the 26.3 beta. If you are on 26.1 or 26.2 and a CLI tool refuses to appear in the list after you add it, that is the known bug and the tool may well have the permission regardless. Test the behaviour rather than trusting the list.

Accessibility and Automation Specifically

These two are grouped because they produce a similar class of confusion.

Accessibility grants an app the ability to control your Mac. Window managers, text expanders, clipboard managers, keyboard remappers, automation tools, and remote support software all need it, and macOS treats it as the powerful grant it is.

Its distinctive behaviour: many apps need a full quit and relaunch, and some need the toggle turned off and back on, before the change registers. If an Accessibility-dependent app stops working after an update, check the code-signing identity cases from earlier first. Accessibility was also one of the panes affected by the macOS 26.1 display bug, with a report on thread 807898 saying the Accessibility variant "has now been fixed in 26.3 Beta."

Automation is structurally different from every other pane. It is not a list of apps but a list of pairs: "App A would like to control App B," each pair a separate decision. If your script controls three applications, you have three decisions and three entries.

Two things follow. A broken Automation permission often means one pair out of several is missing, and the pane is the only place you can see which. And resetting Automation with tccutil reset AppleEvents com.example.controller clears all of that controller's pairings at once, so you will re-approve each target the next time your script touches it. That is often the fastest way out of a stuck Automation state, but be ready for the sequence of prompts.

One trap worth naming: run an AppleScript from Terminal and the grant recorded is Terminal controlling the target app, not your script controlling it. Move the script to a different terminal emulator, or wrap it in an app, and you will approve it again. That is the attribution chain working as designed, which does not make it less surprising the first time.

The Clean Re-Grant Sequence

When you have identified a genuine fault, this is the sequence. Follow it in order. Each step exists for a reason and skipping one is how people conclude the whole exercise does not work.

1. Quit the app completely.

Not just close its window. Quit it with Cmd-Q, then confirm nothing is left:

pgrep -fl "AppName"

If processes remain, they are holding the old permission state and everything you do next will be evaluated against a stale in-memory decision.

Why: a running process caches its permission state. Resetting the database under a live process produces inconsistent behaviour that will send you chasing a phantom.

2. Verify there is exactly one copy of the app on disk.

mdfind "kMDItemKind == 'Application'" -name "AppName"

Delete any copy you are not using.

Why: if two copies exist, you may re-grant the wrong one and end up exactly where you started. This is the step people skip and the reason the sequence fails for them.

3. Confirm the bundle identifier.

osascript -e 'id of app "AppName"'

Why: a wrong identifier gives you the -10814 error at best, and at worst tempts you into dropping the identifier from the reset command entirely, which is the destructive path.

4. Remove the app's entry from the pane.

Open System Settings → Privacy & Security → the relevant pane, select the app, click -. If you are prompted for administrator authentication, provide it.

Why: this deletes the stale decision through the supported interface. It is not the same as toggling the switch off, which records a denial rather than removing the decision. A denial means the app will not be allowed to prompt you again.

5. Reset the service for that bundle identifier.

tccutil reset ScreenCapture com.example.appname

Substitute the correct service name and identifier. SystemPolicyAllFiles for Full Disk Access, Accessibility for Accessibility, AppleEvents for Automation.

Why: the pane and the database can disagree, as the 26.1 bug demonstrated conclusively. Doing both the interface removal and the reset covers you regardless of which one the system is actually consulting. The bundle identifier is not optional here.

6. Relaunch the app.

Why: a fresh process with no cached decision, and no residue from the previous run.

7. Trigger the action that requires the permission.

Start a screen share. Open the folder. Send the Apple event. Do not go back to System Settings and pre-toggle the switch.

Why: the prompt is the mechanism that binds the current signing identity to the decision. That binding is the entire point of this exercise. Pre-toggling a switch in the pane sometimes writes a decision that is not properly bound, which is why people report a toggle that is on and an app that does not work.

8. Approve at the prompt.

Click Allow, or Open System Settings and enable it there if the app is one of the categories that cannot prompt directly, such as Full Disk Access.

9. Quit and relaunch the app once more.

Why: many apps read their capability set only at launch. This step converts "granted" into "actually usable" and eliminates the most common false negative in the whole procedure.

If the app still fails after step nine, the problem is not the permission. Move to the next section.

When Nothing Works

Test With a Fresh User Account

Create a new administrator account in System Settings → Users & Groups, log into it, install or launch the app, and grant the permission there.

This single test splits the problem space cleanly:

• Works in the new account: the fault is in your user account's state, most likely the per-user TCC database, a stale preference, or a login item interfering. The app and the system are fine.
• Fails in the new account too: the fault is system-wide or in the app itself. Your account is not the problem, and a lot of the "delete your preferences" advice you were about to try would have wasted your evening.

It takes five minutes and it is worth more than an hour of guessing.

When a Full Reinstall Is Genuinely the Answer

Reinstalling is the reflex answer to everything and it is usually wrong. It is genuinely right in three situations:

1. codesign --verify reports the bundle is damaged. The signature does not validate; nothing downstream can be fixed. Reinstall from the developer's original download, not from a backup, because the backup may be the source of the damage.
2. The app was installed from a source that modified it. Repackaged installers, tools that patch app bundles, and some corporate deployment mechanisms leave a bundle whose signature no longer matches the developer's. Get a clean copy from the developer.
3. The app's own support documentation says so for the specific symptom you have. Some apps have known permission-state problems with documented reinstall procedures, including steps to clear their own state directories.

Outside those three, a reinstall generally reproduces the same bundle you already have, and if the signing identity is unchanged, the permission situation will be unchanged too.

Restart, But For the Right Reason

A restart clears process state, reloads launch daemons, and resets in-memory caches. It genuinely fixes a class of stuck permission states, particularly ones involving background helpers that will not reload cleanly. It does not fix a code-signing mismatch, a duplicate copy on disk, a damaged bundle, or an application bug. Restart once, early, then go back to diagnosis.

What Not To Do

To be explicit, because these appear constantly in search results: do not disable SIP, which removes protections across the entire system to work around a dialog box. Do not edit or delete TCC.db, which you cannot do with SIP enabled and should not want to do with it disabled. Do not chmod -R your home folder, which does not touch this subsystem and can break your Library folder. And do not run tccutil reset All with no bundle identifier, unless you want to spend the rest of the day clicking Allow.

Managed Macs

If your Mac is administered by an employer or a school, the rules change, and it is worth knowing whether that applies to you before you spend an hour fighting a toggle you were never going to win.

How To Tell If Your Mac Is Managed

Three checks. First, look at System Settings → General → Device Management. If a profile is installed, it is listed there. Second, look for the note in the privacy pane itself: a managed entry displays text saying the setting has been configured by a profile, and its toggle is typically greyed out. Third, from Terminal:

profiles status -type enrollment

On the unmanaged test Mac this returned:

Enrolled via DEP: No
MDM enrollment: No

A managed Mac reports enrolment here instead.

What a Profile Can and Cannot Do

MDM grants permissions through a Privacy Preferences Policy Control payload, usually called a PPPC profile. It writes decisions into the system-wide TCC database directly, which is why a managed Mac can have permissions that appeared without anyone clicking anything.

There are limits, and screen capture is one of them. Kandji, an MDM vendor whose write-up on PPPC changes is widely cited among Mac administrators, describes the mechanism: for screen capture and input monitoring, "IT can use MDM to pre-allow certain apps to be approved even by standard users to enable screen capture or input monitoring." That uses an authorisation value delegating approval to the user rather than granting it silently. So a profile can deny screen capture outright and can let a standard user approve it, but the documented behaviour is that it does not silently grant it the way it can for Full Disk Access or Accessibility.

Hold that nuance lightly, because the Microsoft Q&A case above involved an administrator reporting a system-level TCC record for kTCCServiceScreenCapture with an authorisation reason indicating MDM policy. Those two accounts do not sit together neatly, and I am reporting both rather than picking the tidier one.

If You Use a Managed Mac

Do not try to work around a greyed-out toggle. You will not succeed, and on many deployments the attempt is logged. tccutil reset against a profile-managed entry will either fail or be re-applied at the next management check-in. Contact whoever runs your fleet; the fix is a profile change on their side and takes a minute.

If You Administer a Managed Mac

Match the PPPC payload's code requirement to what codesign actually reports for the deployed version of the app. The Teams case above is instructive precisely because the administrator did verify this and still hit a wall: a correct profile is necessary but not always sufficient. When an app changes its bundle identifier across versions, as Teams did, remove the legacy identifier from the profile rather than leaving both in place.

Troubleshooting Common Issues

The App Is Listed and Toggled On But Still Cannot Record

Problem: The pane shows the app enabled. The app behaves as though it has no permission.

Solution: The entry is bound to a signing identity that no longer matches the app on disk. Run mdfind "kMDItemKind == 'Application'" -name "AppName" first to check for a second copy, the most common cause, and delete any extras. Then run the full clean re-grant sequence, including both the pane removal and the tccutil reset with the bundle identifier. Do not simply toggle the switch off and on; that records a denial followed by an unbound approval, which is how you got here.

The App Disappeared From the List After Updating

Problem: An app that was in the pane yesterday is not there today, and the only thing that changed was an update.

Solution: The new build was signed differently, so macOS sees a new application with no history. There is nothing to repair: launch the app, trigger the protected action, approve the fresh prompt. If the app uses Full Disk Access, which cannot prompt, add it with the + button. If this recurs on every update, the developer's signing setup is unstable and worth reporting to them.

Every Launch Produces a Prompt, Not Once a Month

Problem: The screen capture dialog appears each time you open the app rather than on the expected schedule.

Solution: This is a fault, not the designed re-prompt. The likely causes are an ad-hoc-signed app whose code hash changes on every build, a self-updater replacing its bundle repeatedly, or a launch path that differs each time. Run codesign -dv --verbose=2 on the app and look at the TeamIdentifier line. If it reads not set on a third-party app, that app is not signed with a Developer ID and stable permission is not achievable until the developer fixes their signing.

Two Entries With the Same App Name

Problem: The pane shows the same app twice, sometimes with identical icons.

Solution: Two copies exist on disk with different signing identities or different paths. Find them all with find /Applications ~/Applications ~/Downloads ~/Desktop -maxdepth 3 -name "AppName.app" 2>/dev/null. Keep one, delete the rest, remove both pane entries, then re-grant the survivor. If you keep a beta channel alongside a release build deliberately, expect and accept two entries.

A Command-Line Tool Will Not Appear in the List

Problem: You add a binary with the + button and it does not show up.

Solution: On macOS 26.1 and 26.2 this is the confirmed display bug discussed above, acknowledged by Apple's DTS engineers and reported fixed in the 26.3 beta. The permission is very likely being recorded even though the list does not show it, so test the actual behaviour before troubleshooting further. On any version, plain executables have no bundle identifier and were never first-class citizens in this interface. The durable answer, in Kevin Elliott's words from thread 806187, is to put the tool inside an app bundle and keep using it exactly as before.

The Prompt Names the Wrong Application

Problem: You run a script and the permission dialog names Terminal, or VS Code, or Script Editor, rather than your script.

Solution: This is the attribution chain working correctly. The responsible process is the app you launched, and the permission attaches to it. Either grant the permission to that host application and accept that everything you run inside it inherits the grant, or package your tool as its own app bundle so it becomes the responsible process. Be aware that switching terminal emulators means granting again, because each one is a separate identity.

The Toggle Is Greyed Out

Problem: You cannot change the switch, and there may be a note about a profile.

Solution: The decision is set by a configuration profile. Confirm with profiles status -type enrollment and check System Settings → General → Device Management. On a managed Mac, contact your administrator; the change has to happen in the profile. On a personal Mac showing an unexpected profile, review what is installed there, because a profile you did not knowingly install deserves scrutiny.

Permission Works, Then Stops After Sleep or a Long Session

Problem: Screen sharing works when you start the day and fails after the Mac has been asleep.

Solution: Check first whether what you are seeing is the periodic re-confirmation dialog appearing behind another window, since a prompt you never saw looks exactly like a silent failure. Bring all windows forward and look. If there is no prompt, quit the app fully, confirm with pgrep -fl "AppName", and relaunch, since a helper process that failed to reload after wake is the usual culprit. Restart the Mac once if it persists. If it recurs daily, the app has a wake-handling bug and belongs in a report to its developer.

FAQ

Can I turn off the periodic screen recording prompt?

No. Apple provides no user-facing setting to disable it, and there is no supported command that suppresses it. The only mechanism that removes it is the com.apple.developer.persistent-content-capture entitlement, which is a managed capability developers must apply to Apple for, aimed at remote-control applications. It is not something a user can enable.

How often does macOS re-ask for screen recording permission?

Apple has never documented the interval. The behaviour began in the Sequoia cycle as weekly, and Apple changed it to monthly during that beta after criticism, as MacRumors and 9to5Mac reported in August 2024. Apple's current support page does not mention re-prompting at all, and I could not verify the macOS 26 cadence from any authoritative source.

Will resetting permissions delete my data?

No. tccutil reset deletes recorded consent decisions, nothing else. No files, settings, or app data are touched. The cost is inconvenience: every affected app will prompt again the next time it needs the permission. That cost scales with how broad your reset was, which is exactly why you should always include a bundle identifier.

Why does my app work in Terminal but not on its own?

Because TCC attributes the request to the responsible process, which for a program launched from Terminal is usually Terminal itself. Your program is borrowing Terminal's grant. On its own it has no permission and, if it is a plain executable rather than an app bundle, it may not even appear in the pane to be granted one.

Is Full Disk Access dangerous to grant?

It is the broadest permission macOS offers, covering Mail, Messages, Safari data, Time Machine backups, and other apps' containers. Grant it only to software you would trust with all of that, and note that granting it to a terminal emulator extends the reach to every command you run there.

Do I need to restart my Mac after changing a permission?

Usually not. Quitting and relaunching the affected app is almost always enough, and it is a required step because many apps read their capabilities only at launch. A full restart helps in the narrower case of a background helper or launch daemon that will not reload cleanly. Restart once, then go back to diagnosis.

Conclusion

Most of the frustration in this area comes from treating one label, "permissions", as one thing. It is at least three: POSIX file permissions, which chmod governs and which have nothing to do with any of this; TCC privacy decisions, bound to an app's code-signing identity and stored in databases you cannot read; and, on managed Macs, profile-written policy that overrides what you can change locally.

Once separated, the decision tree is short. A screen capture prompt arriving on a schedule is deliberate, it has no off switch, and the correct response is to click Allow and get on with your day. Everything else is a fault, and faults have causes: a second copy of the app on disk, a signature that changed under an update, a bundle that no longer verifies, a helper that needs its own grant, or an attribution chain pointing at your terminal emulator rather than your script.

The tooling is genuinely thin. tccutil has one verb, Apple does not publish the service names it accepts, and the pane is a view of the database that has been demonstrably wrong before, as the macOS 26.1 display bug showed when Apple's own engineers confirmed permissions were being recorded correctly while the list refused to show them. Work within that: verify the bundle identifier before you build a command, always append it to reset, follow the clean re-grant sequence in order, and test with a fresh user account when you are stuck. And know when to stop. When you have verified the grant, verified the signature, eliminated duplicates, and tested in a clean account, as the Teams reporter on macOS Tahoe 26.4 did, the remaining problem is not yours to fix. Report it and use a workaround while you wait.

Related reading: Mac microphone not working on macOS Tahoe 26.5 · macOS Tahoe security and privacy: the complete guide