MacSouverain

FREN
radar

"No Access", and the app still reads your files

macOS secretly logs access to your files whenever you use the Open/Save dialog. The Privacy & Security interface doesn't show this. Since 2019.

When you open a file via the native selector of an app, macOS writes an attribute directly to the file. This attribute grants the app permanent access, independent of the Privacy & Security settings. You can revoke the app in the System Preferences, the interface will display “No Access”, and the app will continue to read. Since 2019. Without you knowing.

What’s Happening

Howard Oakley, a renowned macOS researcher and author of the blog Eclectic Light, published a demonstration in early April 2026 that sums up the situation in one sentence: the Privacy & Security interface of macOS lies about the real access of applications to your files.

The mechanism is called com.apple.macl. It’s an extended attribute, a small marker that macOS sticks directly onto the targeted file or folder. It’s created automatically when you use the Open/Save selector of an app, when you drag and drop from the Finder, or when you double-click on a file to open it with an app.

This attribute contains two identifiers: one for the app, one for the file. Once set, the app can access the file without passing through the permission checkpoint. It’s managed by the kernel (Sandbox.kext), not the classic TCC system that feeds the settings you see in System Preferences.

And that’s where it gets sticky. System Preferences > Privacy & Security only reads the TCC database. It doesn’t see the com.apple.macl attributes. Result: you revoke an app’s access in the settings, the interface displays “No Access”, and the app keeps its access via the xattr. Oakley demonstrated this with his test tool Insent, notarized by Apple, reproducible by anyone.

Why It Matters to You

This isn’t a bug. Apple introduced this mechanism at the WWDC 2019 (Session 701) under the name “User Intent”, opposed to the classic “User Consent” of the TCC system. The idea: when you explicitly choose a file in the selector, your action is a permanent authorization. No need to ask again.

The problem isn’t the principle. It’s that the interface supposed to show you who has access to what completely ignores this channel. You think you have a faithful dashboard of your authorizations. In reality, you’re looking at half the picture.

And this mechanism has been active since macOS Catalina (2019). Seven years. Confirmed functional on Tahoe (macOS 26). Never publicly documented by Apple in a complete manner. Jeff Johnson, a macOS developer, wrote in 2019: “there’s no documentation of this important privacy protections change.”

In practical terms, it means that every time you’ve used Open/Save, drag and drop, or double-click to access a file in Desktop, Documents, or Downloads, the app potentially received a persistent access that the macOS settings don’t reflect.

A Hacker News thread with 511 points confirms the surprise in the technical community. Several developers report that Apple classified the behavior as “expected behavior” when it was reported.

What You Should Do

Practically:

1. Check if your protected folders have macl attributes. Open Terminal and type: xattr -l ~/Desktop | grep com.apple.macl Repeat for ~/Documents and ~/Downloads. If you see results, apps have a persistent, invisible access in the settings.

2. To revoke a macl access on a sensitive file, the most accessible method: copy the file to another volume (USB key, external disk, other partition), delete the original, recopy the file. The copy doesn’t inherit the com.apple.macl xattr. It’s artisanal, but it works.

3. The technical alternative: boot in Recovery mode and run xattr -d com.apple.macl <file_path>. This requires temporarily disabling SIP, which isn’t trivial. Reserve for users who know what they’re doing.

4. tccutil reset All <bundle_id> followed by a reboot doesn’t suffice. This command resets the TCC database, not the macl xattrs. Oakley himself acknowledges this in his article. The reboot alone doesn’t change anything either, the attribute is embedded in the file system, it survives the reboot.

5. Review the privacy settings on your Mac. They remain useful for controlling the TCC channel (location, microphone, camera, contacts). But keep in mind that they don’t cover this second access channel.

Article #16 guides you through the settings you control. This Radar shows you the ones you don’t control, at least not through the intended interface.

Read: macOS Privacy: The Settings to Change Immediately

Technical terms? Check the glossary.

Sources