Why macOS Sometimes Keeps an App’s File Access Even After You Turn Permissions Off

# Why macOS Sometimes Keeps an App’s File Access Even After You Turn Permissions Off

Because macOS’s TCC (Transparency, Consent, and Control) system separates recorded consent (what System Settings shows) from runtime access conditions (which can include existing process state and certain user-mediated workflows), flipping a permissions toggle can update a stored decision without reliably invalidating every way an app may still be able to reach files immediately. In other words: the switch often updates policy state, but it’s not always an immediate “kill switch” for all the ways an app may already have access.

1) Why turning a permission off doesn’t always cut access

macOS privacy controls can feel binary: a toggle is on, so access exists; the toggle is off, so access is gone. TCC doesn’t always behave that way in practice.

The key mismatch is that TCC is fundamentally about consent decisions that are recorded on disk and consulted at access time—but apps can also retain access through mechanisms that don’t map cleanly to a single on/off UI state. If an app already has a valid route to a folder—through a user-initiated file selection workflow, through cached open resources, or through other system-mediated paths—revocation in System Settings may not immediately sever that route in every edge case.

Practically, community reports and troubleshooting notes describe cases where the System Settings toggle doesn’t appear to immediately align with effective enforcement, even though the recorded consent state has changed.

2) How TCC actually enforces consent (a brief technical primer)

TCC is Apple’s framework for handling permissions to protected resources: not just files and folders, but also items like Camera, Microphone, ScreenCapture, Accessibility, and Full Disk Access (often represented by the service name SystemPolicyAllFiles in tooling).

At a system level, TCC consent data is stored in a SQLite database named TCC.db, found in locations including:

• /Library/Application Support/com.apple.TCC/
• /Users/*/Library/Application Support/com.apple.TCC/

That system-level Application Support location may also contain other TCC-related artifacts beyond the database (for example, caches and detached code-signature related files), so it’s best to think of TCC.db as the primary consent store rather than the only relevant file.

At runtime, access decisions are mediated by Apple’s TCC.framework and the tccd daemon. Those components consult the database and apply policy when an app requests protected capabilities.

For administrators and power users, Apple’s documented tool is /usr/bin/tccutil. Its core function is to reset a recorded decision so the app will be prompted again next time:

• tccutil reset [bundle_id]

Service identifiers are case-sensitive (examples include Accessibility, Camera, Microphone, ScreenCapture, SystemPolicyAllFiles, and All). The catch: tccutil’s capabilities are limited, it’s mostly a reset tool, and the full list of service identifiers isn’t centrally documented and can vary by macOS version.

This is why community guidance often mentions third-party tooling and inspection techniques (like enumerating service identifiers by inspecting strings in TCC binaries), but those approaches come with operational and security tradeoffs.

3) What the recent disclosure showed

Reporting and community analysis (including discussion by Howard Oakley at Eclectic Light) emphasized a recurring theme: the UI state in System Settings doesn’t always appear to match real-world behavior in every edge case, and users sometimes resort to resets to get back to a known state.

Rather than a single canonical reproduction that always behaves the same way, the coverage summarizes inconsistent or surprising behaviors people have reported around Files & Folders-style controls, app access, and what happens after toggles are changed. In some cases, users have found that clearing TCC decisions with tools like tccutil (and occasionally rebooting) was needed to fully restore expected prompting and enforcement.

The important detail is the broader mismatch: the System Settings toggle and the system’s effective enforcement may not align in the way users would expect in certain scenarios, and the remediation people reach for is often a recorded-consent reset rather than relying on the toggle alone.

4) Why this happens: design and implementation factors

The simplest way to understand the issue is that TCC mixes at least two layers:

1. A database of consent decisions (what the OS “remembers” you said yes/no to)
2. Runtime enforcement (what actually blocks or allows access via specific code paths)

Revocation is hard because it can require more than changing a database row. If an app has a live handle to something, or if a system-mediated workflow treats user action as an explicit grant for that moment, you can end up with access continuing even after the recorded preference changes.

Another complication: not all access paths are governed equally. The “prompt-and-store” flow (where TCC asks once, stores a decision, and enforces it later) is only one way apps can get to user data. User-initiated Open/Save panels and some file coordination behaviors can behave like “the user explicitly chose this file/folder right now,” which may not map neatly onto the same revocation semantics as a persistent TCC grant. (This framing is best understood as a practical explanation of reported edge cases, not a definitive statement that Open panels universally bypass revocation.)

Finally, macOS’s official tooling and documentation leave gaps. Community commentary is blunt about this: “these are problems caused by Apple’s poor design, implementation, and documentation of TCC.” Whether or not you agree with the tone, the operational reality is that admins and developers often end up relying on heuristics—resetting, rebooting, or using community tools—because there’s no single, well-documented “revoke means revoke immediately” control surface.

5) Why It Matters Now

This matters because the issue affects modern macOS releases in the Monterey/Ventura era and later builds, which are still common in organizations and among consumers. When users see a toggle in System Settings, they reasonably assume it represents the current truth of access—especially for sensitive locations like Documents.

A mismatch undermines trust: a user can believe they’ve revoked access when enforcement may not change immediately or completely in some cases. That’s especially consequential on shared machines, in enterprise settings, or for anyone handling sensitive documents who relies on privacy controls as part of their workflow. It also ties into broader conversations about “sovereign desktops” and what users expect when they’re told they have control—topics we’ve touched on in Today at TechScan: Sovereign Desktops, Kernel AI Rules, and Surprising Hardware Moves.

6) Practical mitigation steps for users and admins

If you suspect an app still has access after you toggled it off:

• Quit the app completely.
• Toggle the relevant Files & Folders permission off.
• Retest (and consider a reboot if you’re troubleshooting a stubborn case, since community reports sometimes include rebooting as part of getting consistent behavior).

If the mismatch persists, the blunt but documented remediation is to reset the relevant TCC decision using tccutil (many people use broad resets during troubleshooting, but narrower resets are preferable when possible):

• sudo tccutil reset All

In practice, some users also reboot after resets, but exact sequences and whether a reboot is necessary can vary by macOS version and scenario—so treat this as troubleshooting guidance rather than a guaranteed fix.

From a risk perspective, be conservative about granting broad permissions (especially Full Disk Access) unless required. Prefer apps that use standard, expected permission flows rather than utilities that push toward maximal privileges.

For administrators, tccutil is the primary supported tool, but it’s limited. Community tools exist that directly manipulate TCC.db (for example, scripts and utilities built around the SQLite schema), but direct database edits require care and appropriate privileges, and can run into entitlement and system protection constraints. If you go this route, treat it like a change-management operation: test first, document bundle IDs, and avoid ad-hoc edits on production machines.

7) Tradeoffs and limitations of fixes

Resets and database edits are effective precisely because they’re blunt. A full reset forces re-consent prompts and can disrupt legitimate workflows—sometimes across multiple services, depending on how it’s applied. It may also require elevated privileges, and some operations are gated by entitlements (including private ones such as com.apple.private.tcc.manager.access.delete).

Most importantly: users can’t fully “paper over” TCC’s semantics. Apple controls TCC internals, and without clearer UI semantics (what exactly does a toggle revoke, and when?) some mismatch risk will remain.

If you want a broader view of why this matters when institutions try to standardize desktops and permissions, see What Happens When a Government Swaps Windows for Linux — and Why It Matters.

What to Watch

• Apple changes to revocation semantics: Any macOS update that clarifies or tightens how revocation interacts with user-mediated access paths (including Open/Save panels) and related workflows.
• Updates to TCC-related components: Release notes mentioning TCC, tccd, or changes to tccutil behavior and available service identifiers.
• Safer admin tooling: More auditable, least-privilege approaches for managing TCC at scale without fragile direct database manipulation.
• Enterprise guidance: Updated best practices from Apple or MDM vendors on handling “persistent” permissions and recommended remediation steps when UI and enforcement diverge.

Sources: ss64.com, github.com, jetforme.org, kevinyank.com, eclecticlight.co, conzit.com