Over 24 hr period, I had four or five system freezes on my M2 Pro 16GB/512GB MacBook Pro laptop. It was strange – noting too fancy happening – VS Code, Safari, 3-4 lightweight docker containers running Python, Celery, PostGres, Redis and system just randomly freezes.

No warning, no crash dialog — just a frozen screen. Here’s what the diagnostics revealed and how I cleaned things up.

The Symptoms

• Full system freezes requiring a hard reboot (hold power button)
• Finder appearing to crash after reboots
• System Settings showing ~100 GB free, but df -h showing only 23 GB

Step 1: Diagnosing the Freezes

The freezes turned out to be real kernel panics — confirmed by system logs:

log show --predicate 'eventMessage contains "panic"' --last 1dCode language: JavaScript (javascript)

Key findings:

• loginwindow logged: “Previous startup was panic pref was there” after every reboot
• DumpPanic ran at each boot but reported: “3145728 bytes read, but did not contain any paniclog data (buffer was all zeros)”
• AppleARMWatchdogTimer: panic flow Config Engine Trigger NOT found appeared at every single boot

The panic logs being all zeros means the kernel panicked so hard it couldn’t write a log — a sign of a severe kernel-level crash, likely a macOS 26.3.1 bug on Apple Silicon.

A templateMigrator log entry also revealed a recent macOS in-place upgrade, with the old system still present as Previous System on disk.

Step 2: The Disk Space Discrepancy – A REVELATION

System Settings showed ~100 GB free. df -h showed 23 GB. Why the gap?

APFS splits free space into two buckets:

Type	Description
Available	Truly free, usable immediately
Purgeable	Held by macOS — iCloud local copies, caches, Time Machine snapshots

System Settings adds both together. df -h shows only truly available space. df -h is ground truth.

Running df -h in full revealed something more alarming:

/dev/disk3s5     460Gi   416Gi    23Gi    95%   /System/Volumes/Data
/dev/disk5s1      16Gi    16Gi   439Mi    98%   /Library/Developer/CoreSimulator/Volumes/iOS_23B86
/dev/disk7s1     8.2Gi   8.0Gi   245Mi    98%   /Library/Developer/CoreSimulator/Cryptex/...
/dev/disk9s1      18Gi    18Gi   467Mi    98%   /Library/Developer/CoreSimulator/Volumes/iOS_22B81Code language: JavaScript (javascript)

The iOS simulator runtimes were mounted as separate disk volumes — nearly full and not visible in System Settings at all. That’s ~42 GB hidden from plain sight.

The data volume was at 95% capacity. During peak usage (VS Code + Safari + Claude CLI), apfsd diagnostic reports showed the system hitting as low as 11.65 GB free — right when the freezes were happening.

Step 3: Remediation

Remove iOS Simulator Runtimes (~42 GB)

# List runtimes
xcrun simctl runtime list

# Delete by identifier
xcrun simctl runtime delete <identifier>

# Also clean up unavailable simulator devices
xcrun simctl delete unavailableCode language: PHP (php)

Delete Old Android Studio Configs (~420 MB)

Multiple old versions (4.2, 2020.3, 2022.1) were sitting in:

~/Library/Application Support/Google/Code language: JavaScript (javascript)

Safe to delete any version you no longer use.

Clear Developer Caches

# npm cache
npm cache clean --force

# General user cache
rm -rf ~/Library/Caches/*Code language: PHP (php)

Limit Chrome Disk Cache to 1 GB

Chrome doesn’t expose this in its UI, but macOS respects this defaults key:

defaults write com.google.Chrome DiskCacheSize -int 1073741824Code language: CSS (css)

Restart Chrome after running this.

Check Time Machine Local Snapshots

This was the key

A previous incident on this machine found 141 GB held by 3 snapshots from a single day. Always check these when df -h shows unexpectedly low space:

tmutil listlocalsnapshots /System/Volumes/Data
tmutil listlocalsnapshotdates

Delete all at once:

for snap in $(tmutil listlocalsnapshotdates | grep -v "^Snapshot"); do
  sudo tmutil deletelocalsnapshots $snap
doneCode language: JavaScript (javascript)

Note: tmutil disablelocal was removed in macOS Sequoia/Tahoe — it no longer works.

---

Key Takeaways

• df -h is ground truth — System Settings includes purgeable space and lies about free space
• Run df -h without arguments — simulator runtimes mount as separate volumes and won’t show in / alone
• Low disk space can cause kernel panics — macOS needs headroom for virtual memory and swap
• Time Machine snapshots are the silent killer — check them first when space mysteriously disappears
• macOS 26.3.1 has kernel stability issues on Apple Silicon — if panics persist with no panic log data, it’s likely an OS bug; wait for the next update

---

MacBook Pro M2 Pro, 16 GB RAM, macOS 26.3.