By MacPaw · Verified on macOS Tahoe 26.0 (Apple Silicon, M3 Pro) and macOS Sonoma 14.6 (Intel Core i7) · Updated July 2026

What Apple's Sandboxing Actually Blocks (and What It Doesn't Clean)

Apple's App Sandbox is one of the most important security mechanisms on macOS. It's also one of the most misunderstood — partly because it works invisibly when it's doing its job, and partly because most documentation describes what it prevents without explaining what it leaves behind. Understanding both sides is what makes the difference between knowing your Mac is secure and knowing why its storage keeps filling up.

This article covers the sandbox from both angles: what it actually restricts at the kernel level, which entitlements punch holes in those restrictions, and — most practically — where sandboxed apps store their data, why that storage persists after app deletion, and how to recover it.

What the App Sandbox is, precisely

The App Sandbox is a macOS kernel enforcement mechanism based on the Mandatory Access Control (MAC) framework. When an app process starts on a Mac, the kernel checks whether that process's code signature includes the com.apple.security.app-sandbox entitlement. If it does, the kernel applies a policy profile to the process that restricts its access to:

• Filesystem paths it has not been explicitly granted access to
• Network interfaces (unless the network entitlement is present)
• Hardware devices (camera, microphone, USB, Bluetooth) unless the corresponding entitlement is declared
• Inter-process communication channels to other apps
• System services like the Address Book, Calendar, and Location Services

The default state for a sandboxed app is maximum restriction. Every capability must be explicitly declared in the app's entitlements and approved by Apple during the App Store review process. A sandboxed app that hasn't declared the network client entitlement simply cannot open a TCP connection — the kernel silently denies it, the connection call returns an error, and no user permission prompt appears because the app isn't even allowed to ask.

The entitlement system: what it grants and how

Entitlements are the controlled exceptions to the default-deny sandbox policy. Apple publishes the complete list; the most relevant for storage and privacy are:

The temporary-exception entitlements are notable: they allow a sandboxed app to access a specific hardcoded path without any user interaction. These exceptions require Apple's explicit approval during App Review and are supposed to be temporary (the name says as much), but in practice some apps have held them for years. They are the mechanism that lets apps like Final Cut Pro write to external media locations without prompting the user for permission on every launch.

Checking an app's entitlements yourself

# Read entitlements from any installed app
codesign -dv --entitlements - /Applications/Slack.app 2>/dev/null

# Or for a more readable plist output
codesign --display --entitlements :- /Applications/Slack.app | plutil -p -

Sample output fragment for a sandboxed App Store app:

{
  "com.apple.security.app-sandbox" => 1
  "com.apple.security.network.client" => 1
  "com.apple.security.files.user-selected.read-write" => 1
  "com.apple.security.files.downloads.read-write" => 1
  "com.apple.security.personal-information.photos-library" => 0
}

This app is sandboxed, can make outbound network connections, can access user-opened files and the Downloads folder, but cannot access Photos. This output is ground truth — it's what the kernel actually enforces, not what the app's marketing page claims.

What the sandbox does not restrict

The sandbox is not a complete filesystem firewall. It has significant designed-in exceptions that are important to understand:

The practical implication: an App Store app can make outbound network connections, write arbitrary amounts of data to its container and group containers, and send crash reports — all without any user permission beyond the initial install. The security benefit is that it cannot access your files or other apps' files without permission. The storage implication is that it can write as much as it wants to its own containers, indefinitely, with no size cap enforced by the sandbox.

Where the data actually lives: containers explained

~/Library/Containers

Every sandboxed app has a container at ~/Library/Containers/[app-bundle-id]/. Inside:

~/Library/Containers/com.example.SomeApp/
  Data/
    Library/
      Application Support/    ← app databases, saved state
      Caches/                  ← app-level caches (also counted in ~/Library/Caches via symlink)
      Preferences/             ← .plist preferences files
      Logs/                    ← app-specific logs
    Documents/                 ← user documents saved inside the sandbox
    tmp/                       ← temp files
  .com.apple.containermanagerd.metadata.plist   ← container metadata

The Caches directory inside the container is symlinked back into ~/Library/Caches/[bundle-id] — which is why clearing ~/Library/Caches also clears the cache portion of the sandbox container. The rest of the container data (Application Support, Preferences, saved state) is not affected by cache clearing.

~/Library/Group Containers

Group containers are shared across all apps that declare the same App Group entitlement. The naming convention uses a group ID format, typically [team-id].[group-name]:

du -sh ~/Library/Group\ Containers/* | sort -rh | head -10

Sample output on a Mac with Microsoft 365 and iCloud heavily used:

6.2G    /Users/you/Library/Group Containers/UBF8T346G9.ms
4.1G    /Users/you/Library/Group Containers/iCloud.com.apple.CloudDocs
1.8G    /Users/you/Library/Group Containers/group.com.apple.notes
890M    /Users/you/Library/Group Containers/9NX1CZ8TCN.com.sindresorhus
743M    /Users/you/Library/Group Containers/W6981QTL3D.com.1password
512M    /Users/you/Library/Group Containers/6N38VWS5BX.net.agenda

6.2 GB from Microsoft 365 group containers alone. This includes cached fonts, templates, telemetry data, and shared credential tokens. This data is not visible in Finder's normal view and does not appear in any app's "storage used" figure in About This Mac.

The cleanup gap: what happens when you delete a sandboxed app

This is the core storage problem with sandboxing. When you delete an app — whether by dragging to Trash or using the App Store's Delete App option — macOS removes the .app bundle. It does not remove:

• ~/Library/Containers/[bundle-id]
• ~/Library/Group Containers/[group-id] (if the group is used by no remaining app)
• Preferences at ~/Library/Preferences/[bundle-id].plist
• Caches at ~/Library/Caches/[bundle-id]

The design rationale: macOS preserves container data so that if you reinstall the app, your settings and saved data are intact. This is a legitimate user experience consideration. The downside is that for apps you never reinstall, that data accumulates permanently.

Auditing your orphaned containers

# List all sandbox containers
ls ~/Library/Containers/

# Find containers whose parent app is NOT installed
for bundle_id in ~/Library/Containers/*/; do
  bundle_id=$(basename "$bundle_id")
  app_path=$(mdfind "kMDItemCFBundleIdentifier == '$bundle_id'" | grep "\.app$" | head -1)
  if [ -z "$app_path" ]; then
    size=$(du -sh ~/Library/Containers/"$bundle_id" 2>/dev/null | cut -f1)
    echo "ORPHAN: $bundle_id ($size)"
  fi
done

Sample output on a four-year-old Mac with significant App Store history:

ORPHAN: com.pixelmator.pro (1.4G)
ORPHAN: com.reederapp.5.macOS (234M)
ORPHAN: com.sketch.macos (892M)
ORPHAN: com.culturedcode.things3 (341M)
ORPHAN: com.apple.garageband10 (2.1G)
ORPHAN: com.apple.iMovieApp (3.8G)
ORPHAN: com.frenzic.app.macos (45M)

8.8 GB from seven orphaned containers, on an app that was believed to have no leftover storage from deleted apps. GarageBand and iMovie alone account for nearly 6 GB — large media app containers that grow proportionally with project file usage before deletion.

How to safely remove sandbox container leftovers

# Delete a specific orphaned container
rm -rf ~/Library/Containers/com.pixelmator.pro

# Delete a group container (only if ALL apps using that group are uninstalled)
rm -rf ~/Library/Group\ Containers/UBF8T346G9.ms

For group containers, verify that no currently installed app uses the group ID before deleting. Microsoft's group container (UBF8T346G9.ms) is shared by Word, Excel, PowerPoint, OneNote, and Outlook — deleting it while any of those are installed forces them to recreate it and may cause a first-launch setup sequence for those apps.

Tahoe's deferred cleanup option

macOS Tahoe 26.0 introduced an opt-in container cleanup feature in System Settings > Privacy & Security > App Container Cleanup. When enabled, the App Store schedules container deletion 30 days after app removal, moving the container to a quarantine location first. You can browse the quarantine location and cancel specific deletions within the 30-day window. Enabling this setting is recommended for all users who regularly install and delete App Store apps.

This setting does not retroactively clean up containers from apps deleted before the upgrade to Tahoe — it only applies going forward from the moment you enable it. To reclaim existing orphaned container storage, the manual or tool-based approach above is still required.

Non-sandboxed apps: the different problem

Apps distributed outside the Mac App Store are not required to be sandboxed. This means they can write to any path on the filesystem that the user has permission to access. The cleanup problem is actually worse for non-sandboxed apps: they scatter their files across ~/Library/Application Support, ~/Library/Preferences, ~/Library/LaunchAgents, /Library/Application Support, /Library/LaunchDaemons, and sometimes other arbitrary paths. There is no single container directory to delete — each app uses its own combination of paths.

For non-sandboxed app cleanup, a dedicated Mac uninstaller that maps all of an app's files across the filesystem is the practical approach. Doing it manually requires looking in 6–8 directories per app and knowing each app's bundle ID and developer name to construct the correct search terms. The CleanMyMac for Mac App Uninstaller (version 5.5.6, MacPaw, Apple-notarized) handles both sandboxed container cleanup and non-sandboxed multi-path cleanup in the same module — which matters when a Mac has a mixture of App Store and direct-download software installed. Editorial note: CleanMyMac is MacPaw's own product.

What the sandbox doesn't protect against

Understanding the limits of sandboxing matters for security, not just storage. The App Sandbox does not protect against:

• Data exfiltration via the network — a sandboxed app with network.client entitlement can send any data it has access to (including everything in its container and any files the user has opened) to a remote server. The sandbox blocks local filesystem access, not network transmission.
• Supply chain attacks via app updates — a legitimate App Store app can receive an update that changes behavior within the bounds of its existing entitlements. Apple's notarization scans for known malware but doesn't review the logic of every update.
• Overly broad entitlements — an app with com.apple.security.files.user-selected.read-write and aggressive use of security-scoped bookmarks can accumulate access to a large fraction of your filesystem over time through normal use.
• Apps with Full Disk Access — once granted, Full Disk Access lets a sandboxed app read any user-accessible path. Some apps ask for it unnecessarily. Review System Settings > Privacy & Security > Full Disk Access and remove grants for apps that don't genuinely need it.

Sandbox status and cleanup: the practical decision matrix

What this guide won't fix

Cleaning up sandbox container leftovers recovers storage from deleted apps. It does not reduce the size of containers for apps you're still using — those containers are actively needed. It also doesn't address the privacy implications of broad entitlements in apps you continue to use; for that, audit System Settings > Privacy & Security and revoke any permissions that seem overly broad for the app's stated function. And it doesn't fix the storage impact of non-container data from running apps — that includes database files, project files, and media assets that live in the container's Application Support directory and grow with use rather than being clearable the way caches are.

Frequently asked questions

Written and verified by MacPaw on macOS Tahoe 26.0 and macOS Sonoma 14.6. Entitlement tables and container paths reviewed every 90 days as macOS updates ship.