Sysadmins managing fleets of Macs have been asking for per-binary FDA for years because 'Terminal has FDA' effectively meant any script, binary, or malware spawned from a shell inherited unrestricted access to Mail, Messages, and Safari history with no audit trail. The new per-binary grant finally matches how TCC was always supposed to work.
Argues that the old parent-process-inheritance model was functionally 'anything I ever run from a terminal has FDA, forever, with no audit trail,' which malware authors had already noticed and exploited. Tying the grant to a binary's code signature and bundle ID is the right fix for a master-key entitlement that bypasses nearly every other TCC category.
Working developers in the thread point out that rsync, tar, Python scripts, Node CLIs, and build pipelines routinely touch paths under ~/Library and have been silently relying on inherited FDA from Terminal.app. Under the new rules every one of those binaries needs its own grant, which means build scripts and dev workflows are about to start failing in non-obvious ways.
Apple's developer note positions the change as a clarification of how the Full Disk Access entitlement behaves, moving explicitly to per-binary grants surfaced through the standard System Settings prompt and tied to code signature and bundle ID. The framing emphasizes consistency with TCC's Transparency/Consent/Control model rather than treating this as a breaking policy shift.
Apple published a developer note titled *Updates to Full Disk Access in macOS* clarifying how the Full Disk Access TCC entitlement will behave in current and upcoming macOS releases. The short version: Full Disk Access is becoming a per-binary grant, not a per-process-tree grant, and child processes launched by an FDA-approved parent will no longer automatically inherit the parent's access.
In practice, this closes a loophole that developer tooling has been riding for years. If you grant Terminal.app Full Disk Access and then run `rsync`, `tar`, a Python script, or a Node CLI from inside that terminal, those processes have been able to read `~/Library/Mail`, `~/Library/Messages`, Safari history, and the rest of the TCC-protected tree because the kernel evaluated TCC against the parent. Under the new rules, each binary that touches a protected path needs its own FDA grant, surfaced through the standard System Settings → Privacy & Security prompt, and that prompt is tied to the binary's code signature and bundle ID.
The thread on Hacker News (64 points at time of writing) is dominated by two camps: Mac admins who have been begging for this for a decade, and developers who have just realized their build scripts are about to start failing in interesting ways.
TCC — Transparency, Consent, and Control — has always been Apple's answer to the fact that "the user clicked allow once" is a terrible security model. The FDA grant in particular is the master key: it bypasses nearly every other TCC category and gives a process read access to the user's entire home library. For a long time, giving Terminal.app that grant was the pragmatic workaround for engineers who didn't want to click through a dialog every time a shell script touched a dotfile under `~/Library`.
The problem is that "Terminal has FDA" was functionally equivalent to "anything I ever run from a terminal has FDA, forever, with no audit trail." Malware authors noticed this years ago; the standard playbook for macOS stealers has been to drop a shell script and hope the user has already green-lit their terminal. Jamf and other Mac security vendors have published repeated writeups of exactly this pattern. Apple's fix is blunt but defensible: make the grant follow the binary, not the invocation context.
For the enterprise Mac world, this isn't new philosophy — MDM-managed PPPC profiles have been pinning TCC grants to specific team IDs and code requirements for years. What's changing is that the loose, interactive, developer-laptop version of the model is finally catching up. The uncomfortable truth is that most Mac developer tools have been getting a free ride on their users' Terminal.app grant, and that ride is ending.
Compare this to how Linux handles the same problem: it mostly doesn't. SELinux and AppArmor can do finer-grained enforcement, but on a developer workstation, the standard answer is "your user owns the files, your processes read the files." Windows has UAC and a sprawling ACL system but no real equivalent to TCC's per-binary consent for user-space data. Apple's model is genuinely the strictest of the three, and now it's getting stricter.
If you ship a Mac developer tool, a backup client, a sync agent, or any CLI that reads from `~/Library`, three things change for you.
First, helper binaries now need their own entitlements and their own user consent. The pattern of "ship a .app with a GUI, shell out to a helper in `Contents/Helpers/`" still works, but each binary that touches protected paths needs to be code-signed with a stable identifier and will trigger its own FDA prompt the first time it runs. If your installer currently assumes "the user granted the app FDA, we're done," you have an onboarding bug waiting to happen on the next macOS point release.
Second, CI and automation on Mac runners get noisier. GitHub Actions self-hosted runners, Buildkite agents, and homegrown Jenkins setups on Mac hardware have been leaning on the "the launchd agent inherits FDA" trick. That inheritance is going away. The fix is to grant FDA directly to the runner binary (or, better, to deploy a PPPC profile via MDM that pins the grant to the runner's team ID and code requirement), and to stop assuming that `bash -c` from inside the runner has the same access the runner itself does.
Third, shell scripting against protected paths becomes genuinely painful on managed laptops. A one-liner that reads `~/Library/Application Support/...` from a terminal will prompt — or fail silently, depending on how the tool handles EPERM — the first time it runs after the update. Teams that distribute internal tools as shell scripts should consider shipping them as signed executables instead, or routing the access through an already-approved parent application via XPC.
The migration path Apple is nudging developers toward is clear: use XPC services, mach ports, or the standard file-provider APIs to broker access from a signed, user-approved host application, rather than inheriting access from whichever shell happens to have launched you. It's more work. It's also how the platform was supposed to work the whole time.
Expect a wave of "my tool broke on macOS 15.x / 26" issues on GitHub over the next two release cycles, mostly from projects that were quietly depending on parent-process FDA inheritance without realizing it. The security win is real and overdue, but the ergonomic hit lands squarely on the developer tooling ecosystem — the exact group most likely to grant Terminal.app FDA in the first place. The practical move now is to audit your Mac tooling for anything that reads under `~/Library` from a non-GUI process, and get ahead of the prompts before your users do.
IMHO, it's good to add more specific controls for this. After reading this, I went and checked my list of app with full disk access:- Ghostty (fine, it's my terminal)- Alfred (fine, I use it for searching everywhere)Then I have a few turned off:- Spotify (why does it need full disk access)
I don’t quite understand why people complains this is bad for AI agents. Local Code (https://releases.drawthings.ai/p/public-beta-of-local-code-b...) doesn’t require full disk access, when you ask the agent to deal with some files it doesn’t have access to, the built-in ‘permit’
I would like the ability to see which specific folders I have granted access to on an app by app basis. And edit. It’s not clear to me how you revoke an app’s individual folder access after you have granted it.
Any tips on the screenshot utility not getting disk access? Must be related because since macOS 27 it gets a no write permission error.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
> We give developers powerful APIs to build incredible capabilities> Full Disk Access largely sidesteps these controlsThat's because you don't really. Just like you don't give users "powerfulf" controls, so instead they have to resort to dumb ones like "Full disk&