Full Disk Access gets harder to grant. Your terminal may already hold it.

Apple posted a short note to its developer news page on October 2. Full Disk Access, the macOS permission that lets an app read nearly everything on the machine, is going to be harder to grant. The reason Apple gives is agents: as they get more capable and autonomous, the risk of that access "will grow substantially."

The note is about the moment of granting. For a developer who runs a coding agent in a terminal, if that moment happened at all, it probably happened long before any agent arrived, and the permission went to the terminal.

What did Apple actually announce?

A direction, with no date on it. The developer note says Full Disk Access exists so backup apps work, and that it bypasses the controls that otherwise guard private data:

Full Disk Access largely sidesteps these controls in order to allow backup apps to function properly on the Mac. Some developers are using Full Disk Access in ways that could put users at risk, exposing everything on their systems—including files, mail, messages, and even browsing history—without users’ full knowledge and understanding.

Users who want to grant it, Apple says, "can only do so with very explicit user action." The note doesn't say what that action looks like, which macOS release brings it, or whether apps that already hold the permission will be asked again. Apple didn't answer TechCrunch's question about it either.

Why are AI agents in a note about a backup permission?

Because agents have become a new reason to ask for it. TechCrunch points to Meta's Muse, which optionally enables Full Disk Access. An Inc. columnist reported that Muse read his private messages without his permission, and Meta disputes that. The same piece cites a Wired report on a flaw in ChatGPT's Mac app that could have exposed user data. An app built to back up your disk reads it and copies it. An agent that holds the same permission reads it and then decides what to do next.

Does a coding agent launched from Terminal get Terminal's Full Disk Access?

In the ordinary case, by the rules Apple's DTS engineers describe, it can. Neither Apple's note nor TechCrunch mentions terminals, so this part comes from the developer forums. TCC, the privacy layer behind these permissions, works out who is asking by finding the "responsible code," and when a user runs a tool from Terminal, Terminal is the responsible code. A second DTS engineer spelled out what follows:

This is actually how granting FDA to Terminal.app allows "cp" to copy things it couldn't otherwise copy. Terminal doesn't copy anything, but all of it's child processes inherit it's access level, so now Terminal.app-> tcsh* -> cp means "cp" has FDA as well.

Swap cp for a coding agent and the chain looks the same. The agent is a child of the shell, and the commands it runs are its children. When TCC attributes their access to a terminal that holds Full Disk Access, none of them needs a grant of its own. That's my inference from Apple's examples, not something Apple has tested against any particular agent. The same thread says a process an app spawns is attributed to that app, so a desktop agent holding the permission can pass it to the tools it runs.

The difference from cp is who chose the command. cp copied what you typed. The agent decides what to run from what it read, and some of what it reads came from a repository you didn't write.

There are exceptions, and Apple flags them. A launcher can disclaim responsibility, as Xcode does, and helpers started by launchd follow other rules. The engineer who described responsible code also wrote that the exact algorithm "is not documented, has changed in the past, and may well change in the future." Whether the new controls touch attribution, Apple hasn't said.

What does "very explicit user action" protect against?

The next grant, as far as the note goes. Apple hasn't said anything about grants already made, and until it does, extra friction at the grant step does nothing to access already handed out. My read is that it fixes the right moment for consumer apps like Muse, where the agent asks for the disk itself. A developer's Mac is different: if the disk was granted at all, it was granted to whatever runs the agent, and a terminal never says which of its children it's reading for.

I've argued that the tool you install has your reach: a process carries the authority of whoever launched it, decided once and never asked about again. TCC is the per-app layer on a Mac that breaks that pattern, asking for each app instead of handing out the whole account. Full Disk Access on a terminal folds much of it back into ambient authority, and whatever the terminal starts can reach FDA-protected data that its other permissions allow. A harder prompt doesn't change what a grant covers once it's given. Only narrowing does.

What should a Mac developer check this week?

Open System Settings, go to Privacy & Security, then Full Disk Access, and see whether the switch next to your terminal is on. Being on the list isn't the same thing, since blocked apps can show up there too. If it's on, ask why. If one job genuinely needs the disk, the narrower design the DTS engineers discussed is to give the access to a dedicated tool for that job, never to a general interpreter, and to test that TCC really attributes its access to that tool. That moves the grant off the terminal. It doesn't make the agent sandboxed: it still has everything your account can reach without FDA, and taking that away is containment, a different job.

Apple is making the next yes harder. The one on your terminal went to the terminal, and the agent showed up later.