Full Disk Access Mac Terminal: 8 ms Deny vs 40-Hour Hang

On 2 October Apple posted Updates to Full Disk Access in macOS, saying it will add controls so that granting the permission takes "very explicit user action," and naming AI agents as the reason. The post gives no macOS version and no date. Most of the people searching for full disk access for a Mac terminal right now want to know two things: does my terminal have it, and what breaks when it doesn't. I run unattended agents on a headless Mac mini, so I tested the current behaviour instead of predicting the new one.

The short answer from today's run: without Full Disk Access, the paths that only FDA unlocks fail fast, between 7 and 36 milliseconds, every time. The dangerous case is a different permission. On 20 September a single ls ~/Downloads from one of my scheduled jobs waited 40 hours 47 minutes for a consent dialog nobody could see.

Two permissions that look like one

System Settings lists them separately, and the difference decides whether your script errors or freezes. Apple's Privacy & Security guide describes Full Disk Access as access to "all files on your computer, including data from other apps (for example, Mail, Messages, Safari, and Home), data from Time Machine backups, and certain administrative settings." Files & Folders is the other one: Desktop, Documents and Downloads, each granted per app when the app first asks.

The asking is the problem. FDA has no prompt; tccd answers yes or no from its database. The three home folders do prompt, and the process that triggered the prompt waits for an answer.

Test: does my terminal have Full Disk Access?

The check that never prompts is to read a file only FDA can open. The user TCC database is the cleanest target, because it is itself FDA-protected and reading it changes nothing:

$ sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db "select count(*) from access"
Error: unable to open database ".../com.apple.TCC/TCC.db": authorization denied
$ ls ~/Library/Mail
ls: /Users/sg-mini/Library/Mail: Operation not permitted

authorization denied or Operation not permitted means the process tree you are in has no FDA. A number means it does. I ran eight of these probes at 15:01 KST today from my scheduled job, each wrapped in perl -e 'alarm 10; exec @ARGV' as a guard:

Probe	Result	Time
sqlite3 user TCC.db	authorization denied	0.036 s
sqlite3 system TCC.db	authorization denied	0.008 s
ls ~/Library/Mail	Operation not permitted	0.008 s
ls ~/Library/Safari	Operation not permitted	0.007 s
ls ~/Library/Messages	Operation not permitted	0.007 s
ls ~/Library/Cookies	Operation not permitted	0.008 s
ls ~/Library/Application Support/com.apple.TCC	Operation not permitted	0.007 s
ls ~/Library/Suggestions	Operation not permitted	0.007 s

Only the first probe reached tccd. The log has exactly one AUTHREQ for the batch, service=kTCCServiceSystemPolicyAllFiles, authValue=0; the other seven were refused without a new round trip. Do not use ls ~/Desktop as your test. On a Mac where nobody is at the screen it can hang instead of answering.

Who actually gets the permission

The tccd line for that first probe names three processes:

AUTHREQ_ATTRIBUTION: responsible={identifier=com.anthropic.claude-code, pid=36140,
  responsible_path=/Users/sg-mini/.local/share/claude/versions/2.1.287},
  accessing={identifier=com.apple.sqlite3, binary_path=/usr/bin/sqlite3},
  requesting={identifier=com.apple.sandboxd}

sqlite3 did the reading, but TCC judged the responsible process: the Claude Code binary that launchd started. Ninety seconds earlier the same log shows Claude Code 2.1.285 with responsible=com.stablyai.orca, a GUI app on this machine, and that request came back authValue=2, allowed. Same agent, opposite answer, because the app at the top of the tree was different. On a desktop that top app is usually Terminal, iTerm or Ghostty, which is why giving FDA to Terminal works: every shell, script and agent it spawns inherits it.

That inheritance is the complaint in the Hacker News thread on Apple's post (309 points, 219 comments when I read it). One commenter pointed out that "the classic use case for FDA is Terminal app, not backups," and another that "granting terminal full disk access grants arbitrary scripts full disk access." A third put the agent case plainly: if your terminal has access, the Claude inside it does too. My log agrees with all three. Nothing in it records which command asked; it records which app is responsible.

Under launchd there is no terminal at the top. In my case the responsible path is a versioned file, versions/2.1.287, and Claude Code auto-updates. I have not tested whether a grant to one version path carries over to the next. On 20 September the prompt that blocked was attributed to versions/2.1.271, a binary that no longer exists here.

A day of tccd on an agent rig

To see how often this comes up without anyone noticing, I pulled every AUTHREQ_RESULT from the unified log for the last day (2026-10-04 16:18 to 2026-10-05 15:01 KST): 2,648 decisions. 85 were Full Disk Access checks, 73 denied and 12 allowed.

Responsible process	FDA denied	FDA allowed
Homebrew node (two builds)	36	0
Claude Code (launchd-run)	21	0
Apple daemons (XProtect, remindd and 5 others)	12	0
A process named a.out	4	0
GUI apps (Orca, Slack) and zsh	0	12

57 of the 73 denials came from node and Claude Code processes on this rig, and none of them stopped a job. That is the useful part: a missing FDA grant is cheap. The same window had 77 allowed Documents-folder checks and zero AUTHREQ_PROMPTING lines, so no job hung today. I read the log with /usr/bin/log show; how to filter it without drowning is in my tccd logs in Terminal write-up.

What I do on a headless Mac

• No FDA for the agent. Nothing my scheduled jobs do needs Mail, Messages or Safari data, and the denials above show the cost of not having it is a fast error.
• Never enumerate Desktop, Documents or Downloads from an unattended job: no ls, find, du or glob. Scratch work goes in /tmp. This is the rule that would have saved the 16 slots lost on 20 to 22 September.
• Test FDA with the TCC.db read, not with a home folder.
• Schedule with launchd, not cron. crontab is setuid root and hung on a TCC check here; the details are in launchd vs cron on macOS. Whether a job should be an agent or a daemon is covered in LaunchAgent vs LaunchDaemon.

If you do want FDA on your desktop terminal, the path is System Settings > Privacy & Security > Full Disk Access, then the add button and the terminal app. Apple's post says this step will require "very explicit user action" in future. It does not say whether terminals count, and neither does TechCrunch's report on it. Until there is a build to test, I would plan for what is measurable now: a denial you can catch, and a prompt you cannot. Apple events have the same shape of problem on a headless Mac, a 66-second block instead of a clean denial; see Not Authorized to Send Apple Events.

FAQ

How do I check if Terminal has Full Disk Access?

Run sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db "select count(*) from access". "authorization denied" means no FDA for that process tree; a number means FDA is granted. It never triggers a prompt.

Does giving Terminal Full Disk Access give it to scripts and AI agents?

Yes. TCC checks the responsible app, so anything launched from that Terminal window, including shells, scripts and coding agents, inherits the grant.

Why does my script hang instead of failing on a Mac?

Reading Desktop, Documents or Downloads triggers a consent prompt and the process waits for it. With no one at the screen it can wait indefinitely; mine waited 40 hours 47 minutes.

Measured on 2026-10-05 on one machine: Mac mini (Mac16,10, M4), macOS 26.4.1 build 25E253, headless, from a claude -p job started by launchd. The eight probes are single runs, timed with Perl's hi-res clock; the tccd figures come from /usr/bin/log show over a 22-hour-43-minute window, counting AUTHREQ_RESULT lines joined to their AUTHREQ_CTX service by message ID. The 40h47m hang is from my own 2026-09-20 incident log, not re-run: I did not touch any home-folder path in this test, did not grant FDA to anything, and did not test interactive Terminal.app. Apple's change has no version or date yet, so nothing here describes it; quotes are from Apple's 2 October post and the Hacker News thread as of 5 October.