{"id":51549,"date":"2026-04-10T15:40:43","date_gmt":"2026-04-10T19:40:43","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=51549"},"modified":"2026-04-27T11:48:11","modified_gmt":"2026-04-27T15:48:11","slug":"privacy-t-show-intent-based-access","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/04\/10\/privacy-t-show-intent-based-access\/","title":{"rendered":"Privacy & Security Settings Don’t Show Intent-Based Access"},"content":{"rendered":"

Howard Oakley<\/a> (Hacker News<\/a>):<\/p>\n

\n

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.<\/p>\n

[…]<\/p>\n

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.<\/p>\n

[…]<\/p>\n

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.<\/p>\n<\/blockquote>\n\n

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<\/code> and restart<\/em>. (I guess the specific TCC identifier is undocumented; clearly it’s not SystemPolicyDocumentsFolder<\/code>.)<\/p>\n\n

I generally have the opposite problem, with access not<\/em> lasting as long as expected:<\/p>\n\n