Apple Is Tightening macOS Full Disk Access, and Your Terminal Hands It to Every Coding Agent
Apple announced on October 2, 2026 that it will add controls to macOS Full Disk Access, naming AI agents as the reason. The grant attaches to the terminal rather than the executable, so every coding agent launched there inherits it.
- Apple will add controls to macOS Full Disk Access, naming AI agents as the reason.
- The grant attaches to your terminal, not the binary, so every CLI agent you launch there inherits it.
- No enforcement date and no target macOS version were given.
Apple posted a short note titled "Updates to Full Disk Access in macOS" to Apple Developer News on October 2, 2026. It announces that extra controls are coming to the process of granting Full Disk Access on the Mac, and it names AI agents as the reason.
Full Disk Access lets an app you have approved read every file on that Mac. Apple's own user guide scopes it as data belonging to other apps (Mail, Messages, Safari, Home), Time Machine backup data, and certain administrative settings covering all users on the machine. Inside macOS it is handled as a single permission, kTCCServiceSystemPolicyAllFiles. It exists because backup apps needed a path around the normal sandbox.
Here is what Apple wrote, excerpted from the 177-word Apple Developer News post dated October 2, 2026.
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. As AI agents become increasingly capable and autonomous, the risks associated with this level of access will grow substantially.
Apple naming a category of software and announcing a permission redesign around it is not a routine move. What the 177 words never say is when, on which macOS version, or by what mechanism the tightening happens.
The permission attaches to the responsible code, not to the app
The reason this lands on readers of this site is that the "AI agents" Apple points at are not someone else's apps. They are the coding agents you run in your terminal right now: claude, codex, gemini, and anything else you launch from a shell.
TCC, the macOS permission subsystem, does not attach a grant to the binary that is executing. It determines a separate responsible code for that execution and attaches the grant there. Apple Developer Technical Support spelled out the rule in a developer forums answer.
The exact algorithm it uses for this is not documented, has changed in the past, and may well change in the future.
The three cases DTS laid out in that same answer are what you hit in practice.
Launched from a terminal or over SSH
Responsible code = the terminal (or the SSH server)
If the terminal has Full Disk Access,
every CLI you run inside it reads the same scope
| How it was launched | What TCC treats as responsible code |
|---|---|
| From a terminal or over SSH | The terminal, or the SSH server |
| Spawned by an app | That app |
A daemon or agent started by | Requires |
In one sentence: if you turned on Full Disk Access for your terminal, you granted it to every coding agent you launch from that terminal. You never approved the agent separately, and the agent's name never appears in the Full Disk Access list in System Settings. What appears there is the terminal.
Plenty of people switched this on years ago for a backup or sync tool. Back then what ran in that terminal was rsync and shell scripts. What runs in the same window now reads files, executes commands, and makes network calls on its own. The grant has not changed. What uses it has.
The same rule breaking in the opposite direction
The rule cuts both ways, and there is a public record of it failing by not propagating a grant that a user clearly intended.
Issue #24162 in anthropics/claude-code reports the symptom: grant Full Disk Access to Claude.app and the bundled CLI that app launches still cannot read protected paths. The cause is a different signing identity. The desktop app is com.anthropic.claudefordesktop, the bundled CLI is com.anthropic.claude-code, and the CLI executable lives outside the .app bundle under ~/Library/Application Support/Claude/. TCC treats them as unrelated programs.
The reported behavior was an automatic denial with auth_value=5, without a permission prompt ever appearing. Touching a protected file produces sqlite3.OperationalError: unable to open database file. The issue was filed on February 8, 2026 and closed as a duplicate; issue #21737 reports the same symptom from the node binary.
Put the two cases side by side and the shape of the current model shows. Run through a terminal and it opens wider than intended; run inside an app and it closes tighter than intended. Neither outcome is what the user picked. Both fall out of signing identity and execution path. "Very explicit user action," the phrase Apple used, is aimed at exactly this gap.
How far an agent reaches on your local machine is not only Apple's problem. We covered Claude Code mods running in-process with no sandbox, and an agent allowed only GET requests that still got code executed. The OS permission layer is the last fence behind all of it.
What Apple stated, and what it left out
Nothing has changed yet. The post is an announcement of intent with no enforcement date and no target version.
| Item | Detail |
|---|---|
| Who it affects | Every Mac user and every developer shipping a Mac app. No plan or product tier distinction |
| Cost | None. This is a change to a macOS system permission, not a billable product |
| Regional availability | No regional split. The same permission model ships everywhere macOS does, Singapore and the rest of APAC included |
| Prerequisites | None. No application, waitlist, or approval step |
| Enforcement date | Unstated. Apple named neither a date nor a macOS version |
| Mechanism | Unstated. The post says only "very explicit user action" |
Two events frame the timing of the post.
OpenAI published a fix for a local trust flaw in the ChatGPT Mac app (CVE-2026-100754) in its security changelog. The Objective-See Foundation found it, and conversation history was stored locally in plaintext. Fixed in version 26.924.20706.
September 29 to 30, 2026
Inc. columnist Jason Aten reported finding traces of Meta Muse syncing 187,462 rows of his Messages database with Full Disk Access turned off. Meta denied it.
Apple Developer News posts the Full Disk Access announcement.
Meta's rebuttal is specific. Communications VP Andy Stone said the Messages integration is entirely opt-in and requires both Full Disk Access and the Messages connector to be enabled before anything can be read. A Meta Superintelligence Labs executive described three permission stages spanning the app level and the macOS system level, and said no bug routes around them. The two accounts contradict each other directly, and no technical reconstruction has been published by either side. That makes Apple's decision to reopen the permission design at this moment the firmer fact here, more than the dispute itself.
If you use a Mac, open System Settings, go to Privacy and Security, and look at the Full Disk Access list today to see whether your terminal, iTerm, or editor is on it. If one of them is, every coding agent you launch from that window can currently read your mail, your messages, and your Safari history. If you enabled it years ago for a backup or sync tool, leaving it on for that backup app alone and switching it off for the terminal is how you bring the grant back in line with what you actually meant. When Apple does tighten this, the entries that will cost you the most time are the ones sitting in that list whose reason you no longer remember.