An app wants Full Disk Access. What that switch opens, and what to check first

An app has sent you to System Settings to switch on Full Disk Access. Before you do, it helps to know three things Apple documents in separate places: how much the switch opens, why the app could not simply ask, and which narrower permissions exist.

Apple's Mac User Guide says Full Disk Access lets apps "access 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 for all users on this Mac." The wording is identical in the guides for macOS Tahoe 26 and macOS 27. [1] [2] Its device-management reference describes the equivalent setting for managed Macs as access to "all protected files, including system administration files". [3] Mail, Messages, Safari and Home are Apple's examples; neither page gives a complete list of what the switch covers.

An app also cannot ask for this switch with a pop-up. In Apple's Platform Security guide, "Full internal storage access" is one of two permissions an app cannot prompt for; the user has to change it in System Settings. [4] Apple's developer documentation says the same from the other side: an app "can't automatically gain full disk access through an entitlement or with code". [5] If an app asks, it can only point you to the switch. Turning it on is your decision.

A disclosure before the checklist: Kluro is one of the apps that asks. Its Messages page says "macOS requires Full Disk Access for this protected local data." [6] Later in this piece we run the same checks on Kluro, using only what its public pages say.

Who asks, and who has to act

Apple's security guide sorts macOS file and control permissions into two groups. [4]

A request that sends you to Settings is therefore normal for Full Disk Access and tells you nothing about the app either way. What matters is whether the app's job needs the broad switch at all.

Match the job to the narrowest switch

Each row pairs something you might want an app to read with the permission Apple documents for it, and with what else that same permission covers according to Apple.

Sources: Mac User Guide settings table; Files & Folders page; developer documentation on the App Sandbox; device-management privacy keys. [1] [7] [5] [3]

Read the map from the left. If the app's stated job appears in a narrower row, a Full Disk Access request needs an explanation. If the job appears only in a Full Disk Access row, as local Messages history does, the request is expected. The question then shifts to what the app does with the data once it has it.

Six questions before you switch it on

1. Who made this copy of the app? In Terminal, run spctl -a -vv followed by the app's path. It prints whether Gatekeeper accepts the app, a source= line and, for signed apps, an origin= line naming the signer. The shapes we saw are below.
2. What does the vendor say the access is for? Look for a sentence that names the protected data, such as the Messages history stored on the Mac. "Required for full functionality" names nothing.
3. Would a narrower switch do? Use the map above.
4. What leaves the Mac? Find out which content goes to the vendor's servers or to AI providers, which providers, whether processing runs in the background over older history, and what the vendor says about retention. Our four-boundary data-flow check goes into each of these.
5. How do you undo it? Know where the switch is and what a running app does after you change it (see the last section).
6. What happens to copies already made? Revoking stops future reads. Anything the app has already saved or sent is governed by the app's own delete controls and the vendor's terms. Check that a delete control exists before you connect years of history.

What the signer check looks like

We ran spctl -a -vv on a Mac running macOS 26.3 (build 25D125) on 30 September 2026, against three installed apps and a test bundle we built with no signature. The output took four shapes:

$ spctl -a -vv /System/Applications/Messages.app
/System/Applications/Messages.app: accepted
source=Apple System
origin=Software Signing

$ spctl -a -vv /Applications/iMovie.app
/Applications/iMovie.app: accepted
source=Mac App Store
origin=Apple Mac OS Application Signing

$ spctl -a -vv /Applications/Firefox.app
/Applications/Firefox.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: Mozilla Corporation (43AQ936H96)

$ spctl -a -vv "Unsigned Demo.app"
Unsigned Demo.app: rejected
source=no usable signature

Notarized Developer ID means the app came from outside the App Store, was signed by the named developer and was notarized. Apple says a notarized app is one it "checked ... for malicious software and none was detected". [8] That covers malware only. It says nothing about what the app does with your messages, which is why questions 2 to 6 remain. The output format may differ on other macOS versions.

The checklist applied to Kluro

This table uses only Kluro's published pages. It is a worked disclosure, not an independent audit.

The practical reading: granting the permission lets Kluro read your Messages history into a database on your Mac. Its AI explanation adds that "enabled hosted AI processes relevant content for answers and background understanding", so relevant parts of that history reach the model providers above, including in the background. [12] [11] Whether that trade suits you is your call. The Messages source page states the permission plainly.

Turning it off, and what stays

The list lives at System Settings > Privacy & Security > Full Disk Access. Apple's settings page documents how to add an app there. [1] To stop access, switch the app off or remove it from the list; Apple's platform guide describes these settings as the place to "grant or revoke any future access". [13]

Two things are missing from Apple's help pages. The first is timing for a running app. On the macOS 26.3 Mac we checked, System Settings' own text strings include a dialog saying an app "will have full disk access until it is quit", next to a "Quit & Reopen" button. That suggests a running app keeps access until it quits, so quit the app after switching access off. The second is a complete list of the files the switch protects; Apple gives only the examples quoted at the top.

The permission governs reading. Copies the app already made, in its own database or with a provider, follow the app's controls and the vendor's terms, which is why question 6 belongs before you turn the switch on.