Privacy & Security Settings Don’t Show Intent-Based Access
Thus, access to a protected folder by user intent, such as through the Open and Save Panel, changes the sandboxing applied to the caller by removing its constraint to that specific protected folder. As the sandboxing isn’t controlled by or reflected in Privacy & Security settings, that allows TCC, in Files & Folders, to continue showing access restrictions that aren’t applied because the sandbox isn’t applied.
[…]
It’s possible for an app to have unrestricted access to one or more protected folders while its listing in Files & Folders shows it being blocked from access, or for it to have no entry at all in that list.
[…]
Most concerning is the apparent permanence of the access granted, requiring an arcane command in Terminal and a restart in order to reset the app’s privacy settings.
I was aware that access could be granted in this way, but I think I assumed that it only lasted until the app quit. Oakley says that it actually persists until you run tccutil reset All and restart. (I guess the specific TCC identifier is undocumented; clearly it’s not SystemPolicyDocumentsFolder.)
I generally have the opposite problem, with access not lasting as long as expected:
- I keep getting prompts to allow the same apps to access my Documents folder. I’m not resetting anything, but TCC seems to keep forgetting that I’ve granted access.
- Sandboxed apps try to save access to certain folders using security-scoped bookmarks, which keep breaking and needing to be refreshed.
Previously:
- Sploitlight
- TCC and Gatekeeper Bypasses
- Reporting a Full Disk Access Bug to Apple
- Persistent File Access via com.apple.macl Xattr
- Resetting TCC
- Terminal and Full Disk Access
- Sandbox Doesn’t Protect Files From stat()
Update (2026-04-16): Howard Oakley:
Obtaining a definitive list of locations that are subject to privacy protection in macOS Tahoe 26.4 hasn’t been easy, and I’ve previously relied on information given piecemeal in WWDC sessions. This article reports the results of formal testing using a new version of my test app Insent, and brings some surprises.
Update (2026-04-27): Howard Oakley:
Even using a known and simple app like Insent, behaviours aren’t always consistent, and are susceptible to order effects and maybe even cosmic rays! There are also subtle differences between protected locations that can make generalisation unreliable. However, after extensive checks with Insent the following table gives an overview of protected locations in macOS 26.4.
The three common local folders ~/Desktop, ~/Documents and ~/Downloads are most consistent, with controlled read access, GUI controls in Files & Folders, and can be overridden by intent using MACL xattrs. Network volumes also appear to protect write access.
External volumes that are mounted automatically during startup don’t appear to count as being removable, but any that are mounted later have similar protection for both read and write, and can be overridden by intent using MACLs.
iCloud Drive and third-party cloud storage using the FileProvider API are more difficult to investigate, as I’ve still been unable to find any GUI control. It also doesn’t appear to be overridden by intent using MACLs, although its directories can still have com.apple.macl xattrs attached to them.
10 Comments RSS · Twitter · Mastodon
tccutil reset All co.eclecticlight.Insent and reboot doesn't work for me.
The only thing that works for me is to boot into another volume and delete the com.apple.macl extended attribute on the Documents folder.
This depends on how the app has implemented the request for access. Granting access creates a security-scoped bookmark. The app can store it and use it the next time access is required which will bypass the prompt and the bookmark will remain valid in perpetuity (or tcc reset), or the app can not store them and request permission every launch. IIRC the bookmark is a base64 encoded plist containing bunch of data about the file/folder.
A quick search got me this:
https://www.mothersruin.com/software/Archaeology/reverse/bookmarks.html
matt, security-scoped bookmarks are for sandboxed apps. Howard's app is not sandboxed, so security-scoped bookmarks are not applicable.
Apple may be using security-scoped bookmarks, or something like them, internally. Because this sounds similar to current and recent bugs found when using security-scoped bookmarks. Michael recently posted about this issue here: https://mjtsai.com/blog/2025/12/22/the-nofollow-and-resolve-magic-directories/
The actual bug/design appears to be more fundamental to Apple's handling of URLs. I discovered it dealing with security-scoped bookmarks in a sandboxed app. Perhaps Apple encountered similar difficulties, but being Apple, they could just bypass those restrictions in ways that most people wouldn't ever notice. People only complain when they're blocked after all.
Apple's intent for the behaviour of its file system is that users only ever access individual files, not directories. So any attempt to choose and/or subsequently bookmark a directory is going to be risky. My worry is that Apple will simply disable NSOpenPanel.canChooseDirectories and be done with it. For now, any developer that ever uses "canChooseDirectories" should have a backup plan for dealing with situations where the app no longer has access to a previously chosen directory.
It would be nice if these kinds of real-world, low-level issues got some attention. They're complicated and involve edge cases, so they aren't ever sexy enough to ever go viral. Apple developer support has a very consistent response to these issues. They will quote documentation at you explaining how you should use the API. Then they tell you the API is currently broken. They'll also admit that the broken API will not be fixed in the next release. But they promise that the API will most definitely be fixed in some unspecified future version.
Apple doesn't seem to understand or accept that not everyone will update to the current OS version. I certainly don't. Nor can 3rd party developers indefinitely postpone their apps until the day when the required APIs are bug-free. And given Apple's demonstrated level of reliability dealing with bugs, it's unreasonable for any developer to assume that these bugs will stay fixed in future versions. So developers have to code assuming unpredictable failures, implement fallbacks and work arounds, and continually test for new breakage. Or just avoid these features altogether and focus their development efforts strictly on gambling apps.
> Apple may be using security-scoped bookmarks, or something like them, internally.
In this case, they're using the com.apple.macl extended attribute on files and folders.
I'm sure there's more to it than that. As demonstrated, files and folders have significantly different behaviour.
> I'm sure there's more to it than that.
Whatever you want to believe, John Daniel, but I've performed my own tests already, and you could too, instead of just speculating.
Sorry, Jeff Johnson, but I'm not in the business of running tests based on social media posts. This just happens to be one of the rare cases where some social media story seems to reflect what I've already encountered several months ago.
In cases like this, speculation is a more useful strategy than testing. No one outside of Apple really knows the details of how Apple implements a given feature. Just because a developer can see some visible artifact like a file attribute does not give that developer the ability to effectively avoid these kinds of bugs. Apple can, and does, change these implementation details at any time. And this is not a case of, "of course, in theory". This is something that's under active development right now, in production versions of the operating system.
So when a developer sees something like security bugs involving directories in a number of different APIs, that developer can reasonable speculate that APIs relating to directory access are going to be unreliable and code accordingly. Complaining about users or Apple on social media may be cathartic, but it isn't an effective strategy real-world development.
> In cases like this, speculation is a more useful strategy than testing.
Ridiculous.
Generally, speculation is useless, and specifically, your speculation in this case is wrong.
> Just because a developer can see some visible artifact like a file attribute does not give that developer the ability to effectively avoid these kinds of bugs.
Nobody said it can be avoided.
Well, it can be avoided by disabling SIP, but otherwise not.
> This is something that's under active development right now, in production versions of the operating system.
There's no evidence that this has changed or is changing. It's simply an obscure situation that hasn't been explored before. It's possible that nothing much has changed since I wrote about macl in Catalina 6 years ago: https://lapcatsoftware.com/articles/macl.html
> that developer can reasonable speculate that APIs relating to directory access are going to be unreliable and code accordingly.
I'm not sure why you're making this into a developer issue. On the contrary, it's a Mac user issue.
