Disk full but no large files to delete

After this, "Available" in Finder's Get Info matches what you'd expect from what's actually on the drive.

Why this happens

Apple's documented policy is that macOS keeps an hourly local snapshot for 24 hours, plus one extra snapshot of the last successful Time Machine backup "until space is needed," plus one more taken automatically right before any system update installs. Local snapshots are incremental — each only stores what changed since the last — but if a Time Machine destination has been unreachable for a while (an external drive left unplugged), they pile up because macOS can't confirm the data is safe elsewhere yet. They live inside the APFS container itself, which is why df reports the space as used but no file browser shows where it went, and why it's counted as "purgeable" rather than "used" in Disk Utility.

One thing worth knowing before you assume it'll clear itself: a documented test by Howard Oakley (Eclectic Light, August 2026) filled a disk to 95% and found macOS repeatedly failed to automatically purge the purgeable snapshot space even once free space actually ran out — it eventually had to be cleared manually. Don't assume waiting will fix it; the thinning command below is the reliable path.

If step 1 below shows the disk genuinely isn't full of snapshots, the next most common real cause on a developer machine is Xcode — DerivedData alone commonly reaches 30GB+, and installed simulator runtimes add several gigabytes each; one documented cleanup recovered over 160GB combined from simulators, DerivedData, and device support files. Old iOS device backups under ~/Library/Application Support/MobileSync and a bloated Photos library derivatives cache are the other two repeat offenders.

Fix it

1. Check how much of the disk is actually reported used, and how many local snapshots exist:

   ● Reads the system

   What it does: prints disk capacity and usage for the startup volume.

   After: nothing changes, this only reads.

   df -h /

   Copy

   Output

   Filesystem        Size    Used   Avail Capacity iused ifree %iused  Mounted on
   /dev/disk3s1s1   228Gi    12Gi    57Gi    18%    459k  599M    0%   /

   Captured live on the verification machine — a healthy 18% used with plenty free. If your Capacity reads 90%+ and this doesn't match what you'd expect from your files, check snapshots next.

   ● Reads the system

   What it does: lists local APFS snapshots currently held on the startup disk.

   After: nothing changes, this only reads.

   tmutil listlocalsnapshots /

   Copy

   Output

   Snapshots for disk /:

   Captured live on the verification machine — zero snapshots listed, which matches the healthy 18% usage above. On a machine that's actually full for this reason, this same command lists one line per snapshot, often dozens, each dated.

2. If step 1 turned up a long list of snapshots, thin them down to reclaim space. This only removes local snapshot data — it does not touch your actual files, and Time Machine will simply start a fresh snapshot cycle afterward.

   ▲ Changes settings

   What it does: purges local snapshots on / until roughly 10 GB is reclaimed, or 4 snapshots minimum are removed.

   After: reported free space increases; nothing else on the disk changes.

   tmutil thinlocalsnapshots / 10000000000 4

   Copy

   Revert: nothing to restore — snapshots regenerate automatically as part of the normal backup cycle.

   Output

   Thinned local snapshots:

   Captured live on the verification machine — empty because there were no snapshots to thin (matches step 1). On a disk with real snapshot bloat, this line is followed by the date of each snapshot removed.

3. If snapshots weren't the cause, find what actually is. Disk Utility's volume info panel shows a "Snapshots" line with the exact size in use — check that first if you want a GUI answer. For a full breakdown from Terminal:

   ● Reads the system

   What it does: lists the 15 largest top-level directories on the startup disk.

   After: nothing changes, this only reads. Takes a while on a full disk.

   sudo du -x -d 3 / 2>/dev/null | sort -rh | head -15

   Copy

   On a developer machine, ~/Library/Developer/Xcode/DerivedData and installed simulator runtimes under CoreSimulator are the usual surprise — tens of gigabytes is normal, not a bug. ~/Library/Application Support/MobileSync/Backup (old iOS device backups) is the other repeat offender, and old backups aren't removed automatically even after you've made newer ones.

Still broken?

• Xcode and its simulators are the ones actually eating the space — a common second cause on developer machines, worth checking directly rather than assuming it's snapshots.
• Check whether this is a known issue with the current macOS version

Verified on

Both command outputs above were captured live on the M3 / macOS 26.6 row.

Related problems

• Invalid active developer path
• What's broken in macOS 26 so far