macOS 27 locks away some app data, and cleaners now see less
macOS 27 denies apps access to other developers' app data by default. What Apple changed, what we saw in testing, and why disk tools may now under-count.
On this page
If your disk analyzer or cleaner started finding less after you updated to macOS 27, your Mac probably didn't get tidier. macOS 27 stops apps from reading some other apps' data by default, and a tool that doesn't report what it was refused will simply show smaller numbers.
What Apple changed
Two entries in Apple's macOS 27 release notes cover it. The first:
Accessing files in other developer teams' app data containers and app group containers no longer prompts the user for authorization; such accesses are denied by default and can be managed by the user in Privacy & Security settings. (161835690)
Before, an app reaching into another developer's container would trigger a permission prompt. Now the answer is simply no, unless you've said otherwise in System Settings. The second entry goes further than containers:
XProtect may now restrict access to app data that is commonly targeted by malicious software. Accessing files created by other developer teams' apps may be denied by default but may be managed by the user in Privacy & Security settings. (178668601)
Apple doesn't say which apps' data is covered, and because the list comes from XProtect it can change without a macOS update.
What it looked like in testing
I tested this with Spaceback, which is sandboxed and scans only folders you grant it. On macOS 27.0, listing the ~/Library/Application Support folders of Chrome, Firefox, Microsoft Edge and Discord failed with a permission error, where the same code had read them on macOS 26. Their caches, in ~/Library/Caches, were still readable.
That pattern fits the second release note. Browser profiles hold cookies and saved logins, and chat apps hold session tokens. That's exactly what info-stealing malware goes after, and it's the data you least want any app, well-meaning or not, reading in bulk. I think it's a good change.
Why disk tools quietly under-count
Most code that walks a folder tree was written when "permission denied" was rare, so a lot of it skips errors and keeps going. On macOS 27 that means a protected folder is added to the total as zero bytes. The tool doesn't crash and doesn't warn you. The total is just wrong, and wrong in the comfortable direction.
I know because Spaceback had exactly this bug when I first ran it on the macOS 27 beta: every place the scanner listed a folder treated a refusal as an empty folder. We changed it in August, so a refused folder is now reported as refused rather than counted as nothing. The effects you might notice in any tool:
- A disk map shows a smaller total than before, and less than Storage settings.
- An uninstaller "removes everything" but leaves a browser's or chat app's data behind, because it never saw it.
- Numbers from Terminal don't match numbers from an app, because they're allowed to see different things.
What you can do about it
For most people, nothing. The protected folders are the kind of data you shouldn't be deleting by hand anyway: a browser profile isn't clutter, it's your history, logins and extensions. If you want to clear a browser's data, do it from the browser's own settings.
If you do need a tool to see these folders, Apple says access can be managed in System Settings → Privacy & Security. Its known-issues list also mentions granting access to specific apps' data under Files & Folders, and notes that command-line processes without a bundle ID can't be given that kind of per-app access. Apple's suggested workaround for those is to give the tool Full Disk Access for as long as you need it (184660124). That's also why du in Terminal can see things a sandboxed app can't, and the other way round.
Be choosy about who gets Full Disk Access. The whole point of this change is that a tool with broad access can read the data malware wants, and "it's a cleaner" doesn't make it trustworthy.
What Spaceback does
The Mac App Store version doesn't ask for Full Disk Access and doesn't try to route around this protection. When macOS refuses a folder, Spaceback says which folders it couldn't read instead of pretending they're empty, so the total it shows is the total it actually measured. That can be smaller than what other tools show, and at least you know why.