Home › Blog

Why apps ask for Full Disk Access, and what you are agreeing to

28 August 20268 min read

It is the only macOS permission that cannot ask for itself. Every app that needs it has to write a small set of instructions and hope you follow them, which is why they all feel slightly awkward about it.

Full Disk Access is the permission that makes everyone slightly uncomfortable, and it should. It is also routinely misunderstood in both directions: people grant it without thinking to anything that asks, or refuse it to software that genuinely cannot work without it and then conclude the software is broken.

It is worth ten minutes to understand properly, because it is the only permission on macOS you have to grant entirely on your own initiative.

What it actually covers

The name is misleading. Full Disk Access does not grant access to the full disk, and it is not administrator rights. Your Mac already lets any app you run read most of your files: your Documents, your Downloads, your Desktop, your entire home folder. No special permission is involved and none ever was.

What macOS protects separately is a specific list of places, guarded by a subsystem called TCC, for Transparency, Consent and Control. Full Disk Access unlocks that list. Roughly:

• Mail, at ~/Library/Mail. Every message and every attachment.
• Messages, at ~/Library/Messages. The full iMessage and SMS history as a readable database.
• Safari, at ~/Library/Safari. Browsing history and bookmarks.
• Photos originals, the full resolution files inside the library.
• Time Machine backups, which by definition contain everything else.
• Other apps' containers, the private per-app folders in ~/Library/Containers.
• Some removable volumes and network shares, depending on your other privacy settings.

That is the whole scope. It is a meaningful list, because it is more or less exactly the set of things a person would consider private. It is also considerably narrower than "full disk", and it grants no ability to modify system files, install anything, or act as another user.

Why no app can ask you for it

Here is the part that produces most of the confusion. Camera access, microphone access, contacts, calendar and location can all be requested by an app, at which point macOS shows a dialog and you click yes or no.

Full Disk Access has no such mechanism. Apple provides no API to request it. There is no dialog an app can trigger. The only path is:

1. You open System Settings.
2. You go to Privacy & Security, then Full Disk Access.
3. You add the app yourself, by hand.

This is deliberate, and it is a good design. It means the decision is always yours, made in Apple's own interface, with no pressure from a dialog that appeared while you were trying to do something else. Nothing can nag you into it, and nothing can make the button look like a different button.

It also means every app needing it has to write a small tutorial and hope you follow it. Any app that claims it will request the permission for you has misunderstood the platform.

Why you have to quit and reopen the app

This is the most common failure, by a wide margin. Someone grants the permission, returns to the app, sees no change, and concludes it did not work.

macOS evaluates an app's permissions when the process starts. A running app keeps whatever it had at launch. Adding it to the Full Disk Access list updates the setting, but the process that is already running does not get retroactively upgraded.

So the sequence has to be: grant the permission, quit the app completely with Command-Q, then open it again. Closing the window is not enough, because the process is still alive. If the app has a menu bar icon, check that it is actually gone.

Every app that needs this permission tells you to quit and reopen. Almost nobody does it the first time, which is why almost everybody's first attempt appears to fail.

Why a disk analyser asks for it at all

A tool that reports where your disk space went has a specific problem: the folders it cannot read are frequently the large ones.

Without Full Disk Access, a scan silently skips Mail, Messages, Safari data, Photos originals and every other app's container. On a Mac where Mail is holding 30 GB of attachments, the scan reports a total that is 30 GB short, and there is no indication of what is missing. You get a confident answer that is wrong, which is the worst kind.

This connects directly to the "my free space does not match the folder sizes" problem described in the article on finding large files. Skipped folders are one of the three usual causes, and it is the one nobody thinks of because nothing announces it.

Strata handles this by testing rather than assuming. It attempts to read several of the protected locations at launch and reports what it found. If access is missing it tells you, shows the steps, and still scans everything it can reach, marking the total as incomplete rather than presenting a short number as if it were the truth.

What silently takes the permission away again

Granting it once is not always granting it forever, and the ways it comes undone are not announced.

macOS records the permission against the app's identity, which means its bundle identifier together with its code signature. Change either and the entry in the list may still show the app's name while no longer applying to the app you are running.

Moving the app. Drag it from Downloads to Applications after granting access and the permission can stop applying. Always move an app to its final home first, then grant the permission.

Some updates. An ordinary update from the same developer keeps the permission, because the signature still matches. An update that changes signing certificates does not, and you will simply find the app can no longer read what it could yesterday.

Having two copies. If there is a version in Downloads and another in Applications, the permission applies to whichever one you actually added. Launching the other produces an app that appears to be listed and permitted and behaves as though it is not.

If you suspect something is stale, remove the entry with the − button and add it again from its current location. That is faster than diagnosing which of the three happened.

How to decide whether an app deserves it

A real decision, so here is a real framework rather than a shrug.

Ask what it needs to read. A backup tool, a disk analyser, an antivirus scanner and a search tool all have honest reasons. A wallpaper app, a calculator or a menu bar clock do not. If the connection between the app's purpose and your email is not obvious, that is the answer.

Check who wrote it. Open the app's Info panel and look at whether it is signed and notarised by a named developer. Notarisation is not an endorsement, but an unsigned app asking for read access to your messages deserves considerably more scepticism than a signed one.

Consider whether it sends anything anywhere. This is the question that actually matters. Read access to your Mail folder is only as dangerous as what the app does afterwards. Software that works entirely locally and makes no network requests is a fundamentally different proposition from software that syncs to a server, regardless of how similar the permission dialog looks.

Review the list occasionally. Open System Settings, Privacy & Security, Full Disk Access, and read it. There will be entries you do not recognise and apps you uninstalled two years ago. Removing something from that list is instant and completely reversible, so there is no cost to being aggressive about it.

Granting it, step by step

1. Open System Settings.
2. Privacy & Security, then scroll to Full Disk Access.
3. Click the + button. You may be asked for your password or Touch ID.
4. Choose the app from your Applications folder.
5. Make sure its toggle is on.
6. Quit the app completely and open it again.

To take it away later, either switch the toggle off or select the app and click −. It takes effect the next time that app launches, by the same rule as granting it.

Common questions