If you upgraded to macOS Sequoia and suddenly your Mac's storage is nearly full for no obvious reason, you are not imagining it. Several Sequoia-era changes — new snapshot behavior, expanded system caches, and background indexing activity — quietly eat gigabytes that never appear as normal files. This guide walks through eight hidden culprits behind the "why is my Mac storage full Sequoia" mystery, with real paths and Terminal commands so you can investigate each one yourself.
1. Local Time Machine Snapshots
macOS has created local APFS snapshots for Time Machine backups since High Sierra, but Sequoia is more aggressive about retaining them when your external drive is disconnected. These snapshots do not appear in Finder and are invisible to most storage tools.
To list them:
tmutil listlocalsnapshots /To see how much space they occupy:
tmutil listlocalsnapshotdates / | tail -n +2 | while read d; do tmutil localsnapshot /; doneA quicker check:
tmutil listlocalsnapshotdates /Safe to delete? Yes, with caution. Snapshots are meant as short-term rollback points. You can remove old ones with:
tmutil deletelocalsnapshots YYYY-MM-DD-HHMMSSmacOS will also reclaim snapshot space automatically when your disk is critically full, but it may not act until you are down to single-digit gigabytes.
2. App Container Caches in ~/Library/Containers
Sandboxed apps write caches, logs, and support files inside ~/Library/Containers/<bundle-id>/Data/Library/. After upgrading Sequoia, apps often rebuild these caches from scratch, leaving the old cache alongside the new one until the app cleans up — which some never do.
Check the total size:
du -sh ~/Library/ContainersFind the biggest offenders:
du -sh ~/Library/Containers/* | sort -rh | head -20Cache subfolders inside Containers are generally safe to clear; the Data/Documents subfolder may contain important app data and should not be touched without understanding what the app stores there.
3. Spotlight Re-indexing Writes
A major OS upgrade triggers a full Spotlight re-index. During this process, /.Spotlight-V100 on each APFS volume can swell temporarily. On some Macs this runs for 12–24 hours post-upgrade. You can see whether it is still running:
mdutil -s /If the output says "Indexing enabled. Scan base phase in progress," the index is still being built. Give it time; the temp space is reclaimed once indexing completes. If it seems stuck after several days:
sudo mdutil -E /This forces a fresh index rebuild and usually resolves runaway index files. Do not delete the Spotlight folder manually.
4. Leftover macOS Installer Packages
The Sequoia installer application itself — often over 13 GB — sits in /Applications after the upgrade completes. macOS does not remove it automatically.
ls -lh /Applications/Install\ macOS\ Sequoia.appIf the upgrade is finished, this is safe to delete by dragging it to the Trash. Similarly, check ~/Downloads and /Library/Updates for older OS installer files:
du -sh /Library/Updates/*5. iOS Device Backups
iTunes / Finder device backups live in:
~/Library/Application Support/MobileSync/Backup/Each full iPhone or iPad backup can be 5–50 GB. Sequoia did not change this behavior, but the upgrade is a natural moment when users connect devices and trigger new backups without removing old ones. Open Finder, connect your iPhone, go to the General tab, and click "Manage Backups" to delete obsolete copies.
6. System and User Log Accumulation
macOS writes logs to two main locations:
/var/log/— system-wide logs (requires sudo to inspect)~/Library/Logs/— per-user app logs/Library/Logs/— system-level app logs
du -sh ~/Library/Logs
du -sh /Library/LogsUser-level logs in ~/Library/Logs are safe to clear. System logs in /var/log are managed by the OS (via newsyslog) and should generally be left alone. Crash reports in ~/Library/Logs/DiagnosticReports are safe to delete after you have reviewed them.
7. Xcode Derived Data and Device Support
Even if you only use Xcode occasionally, it accumulates gigabytes in:
~/Library/Developer/Xcode/DerivedData— build artifacts, often 10–30 GB~/Library/Developer/Xcode/iOS DeviceSupport— symbol files for every iOS version you have debugged on~/Library/Developer/CoreSimulator/Caches— simulator runtime caches
DerivedData is rebuilt automatically next time you build, so it is entirely safe to delete. Old DeviceSupport folders for iOS versions you no longer test on are also safe to remove.
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport8. Orphaned App Leftovers After Uninstalling
Deleting an app by dragging it to the Trash removes only the .app bundle. Every macOS app can leave behind files scattered across:
~/Library/Application Support/<AppName>~/Library/Preferences/com.developer.appname.plist~/Library/Caches/<bundle-id>/Library/Application Support/<AppName>/Library/LaunchDaemons/and/Library/LaunchAgents/
These leftovers accumulate invisibly. A handful of large apps — video editors, virtual machines, security tools — can each leave behind 1–5 GB of support files that are never cleaned up automatically.
How to Find All Eight in One Scan
Crumb runs a whole-Mac audit that maps every category above — snapshots, container caches, logs, installers, Xcode data, and app leftovers — into a single sorted list so you can see what is actually using your disk without running a dozen Terminal commands. Its Uninstall view also shows leftover files from previously deleted apps, grouped by app, so you can review and remove them safely rather than hunting through Library folders manually.
For any folder you are unsure about, Crumb's "Is this safe to delete?" feature explains what the folder contains and its removal risk before you commit. Since cleaning is permanent (emptying the Trash cannot be undone for most system caches), understanding what you are deleting matters.
If you want to try it, you can download Crumb and run a free scan to see where your space went.
Quick Reference: Safe vs. Careful
| Location | Typical Size | Safe to Delete? |
|---|---|---|
| Old Time Machine snapshots | 2–20 GB | Yes (use tmutil) |
| App container caches | 1–10 GB | Cache subfolder: yes |
| Spotlight index temp files | 1–5 GB | Wait; use mdutil -E if stuck |
| macOS Sequoia installer | ~13 GB | Yes, after upgrade completes |
| Old iOS device backups | 5–50 GB | Yes, via Finder Manage Backups |
| ~/Library/Logs | 100 MB–2 GB | Yes |
| Xcode DerivedData | 10–30 GB | Yes (rebuilt on next build) |
| App leftovers in ~/Library | 1–5 GB per app | Usually yes; verify per app |
Summary
Most of the storage mystery on Sequoia comes down to a few patterns: the OS upgrade triggers background processes (indexing, snapshots, cache rebuilds) that temporarily or permanently consume space, and years of app installs leave orphaned files that nobody removes automatically. Work through the eight categories above, use Terminal to verify sizes before deleting, and be cautious with anything outside ~/Library/Caches and ~/Library/Logs if you are not certain what it belongs to.