Dev Tools Storage Cleanup on macOS: Reclaim 100GB+ from Cursor, Xcode, Docker, and More

1. Why Dev Tools Silently Eat Your Disk

Developer tools have a storage problem by design. They cache aggressively to be fast, they keep old versions for rollback safety, and they rarely clean up after themselves. On a Mac with a 512GB SSD, you can easily lose half your disk to tooling bloat without any visible warning.

The biggest offenders follow a predictable pattern: they write data to Library directories, Application Support folders, or hidden dotfile locations that macOS Storage Management does not surface clearly. You see "System Data" taking 200GB in Settings and have no idea what it actually is.

2. Auditing Your Current Storage Usage

Before cleaning anything, you need to understand where space is actually going. The built-in macOS storage view is nearly useless for developers because it lumps everything into vague categories. Here are the commands that actually tell you what is happening:

Third-party tools like GrandPerspective or DaisyDisk give you a visual treemap that makes it easy to spot outliers. OmniDiskSweeper is free and functional. For CLI purists, ncdu (install via Homebrew) is the gold standard.

Write down the top offenders and their sizes before you start cleaning. You want to measure the actual space reclaimed, not guess.

3. Cursor and VS Code: Snapshots, Extensions, and Cache

Cursor (and VS Code, which shares the same Electron base) stores data across multiple locations. The one that caught the Reddit user off guard is the workspace storage and backups system, which can grow unbounded.

The key culprit is usually the User/workspaceStorage directory inside Application Support. Each workspace you have ever opened gets a folder, and old ones never get cleaned up. The Backups folder can also grow large if you have file history enabled.

Clearing workspace storage will lose per-project state like open tabs and undo history, but it will not affect your settings, keybindings, or extensions. For most people that is a good trade.

4. Xcode: Derived Data, Archives, and Simulators

Xcode is the single most aggressive disk consumer on macOS. Between derived data, old archives, simulator runtimes, and device support files, a typical iOS developer loses 50-150GB to Xcode-related artifacts.

• Derived Data (~/Library/Developer/Xcode/DerivedData/) - Build intermediates. Safe to delete entirely. Xcode rebuilds what it needs. Commonly 20-80GB.
• Archives (~/Library/Developer/Xcode/Archives/) - Old app builds you submitted to App Store. Keep recent ones, delete anything older than a few months. Each archive is 200MB-2GB.
• iOS Device Support (~/Library/Developer/Xcode/iOS DeviceSupport/) - Symbol files for each iOS version you have debugged on a physical device. Each version is 2-5GB. Delete old iOS versions.
• Simulator Runtimes - Each downloaded simulator runtime (iOS 16, 17, 18) is 5-8GB. Remove unused ones from Xcode Settings or via xcrun simctl delete unavailable.
• CoreSimulator Caches (~/Library/Developer/CoreSimulator/) - Simulator app data. Can grow large if you test many apps.

Some developers set up a cron job to wipe DerivedData weekly. The trade-off is a slightly longer first build on Monday morning, but you never have to think about it growing out of control.

5. Docker: Images, Layers, and Build Cache

Docker Desktop on macOS runs inside a Linux VM, and all of its data lives in a single disk image file. This file only grows - it never shrinks automatically, even if you delete containers and images.

Even after pruning, the Docker.raw disk image file may not shrink. To actually reclaim that space, you need to go to Docker Desktop Settings and reduce the disk image size, or in extreme cases, reset Docker Desktop entirely (which deletes all images and containers).

Alternatives worth considering: OrbStack is significantly more storage-efficient than Docker Desktop on macOS. Colima is another lightweight option. Both use less disk space by default and have better disk reclamation behavior.

Set Docker Desktop's disk limit to something reasonable (32-64GB) in settings. This prevents it from silently eating your entire disk when you forget about a running build.

6. Other Offenders: Homebrew, npm, pip, and Application Support

Beyond the big three, there are dozens of smaller storage leaks that add up. Here are the most common ones and how to clean them:

• Homebrew - Old formula versions stick around. brew cleanup --prune=7 removes downloads older than 7 days. brew autoremove uninstalls unused dependencies. Typically saves 2-10GB.
• npm / pnpm / yarn - Global cache at ~/.npm/_cacache or ~/Library/pnpm/store. Run npm cache clean --force or pnpm store prune. Also check for orphaned node_modules in old projects using npx npkill.
• pip / conda - Pip cache lives at ~/Library/Caches/pip. Conda environments at ~/miniconda3/envs or ~/anaconda3/envs. Clean with pip cache purge and conda clean -a.
• Rust / Cargo - The ~/.cargo/registry and target directories in Rust projects can be enormous. Use cargo cache -a (install with cargo install cargo-cache).
• Go modules - Module cache at ~/go/pkg/mod. Clean with go clean -modcache.
• Application Support misc - Slack caches media aggressively (5-20GB). Chrome profiles grow unbounded. Claude Desktop stores conversation caches. Check everything in ~/Library/Application Support/ and ~/Library/Caches/ sorted by size.

A good practice is to run du -sh ~/Library/Caches/* | sort -hr | head -10 monthly. Caches are generally safe to delete - applications rebuild them as needed. Application Support is trickier and should be evaluated per-app.

7. Weekly Cleanup Scripts and Automation

Manual cleanup works once but the problem comes back. The sustainable solution is automation. Here is a weekly cleanup script that covers the major offenders:

Schedule this with a launchd plist or a cron job. For cron, add 0 9 * * 1 ~/scripts/weekly-dev-cleanup.sh to run every Monday at 9am.

For more sophisticated automation, desktop AI agents can handle this kind of routine maintenance. Fazm, for example, can be instructed to monitor disk usage, identify bloated directories, and run cleanup routines on a schedule - treating it like any other macOS task rather than requiring you to maintain shell scripts manually.

Other automation-friendly options include Hazel (rule-based file management), CleanMyMac (GUI with scheduled cleaning), and custom launchd agents. The best approach depends on whether you prefer scriptable control or a visual interface.

Whatever method you choose, the key insight is that dev tool cleanup is not a one-time task. It is ongoing maintenance, and the tools that eat your disk today will eat it again next month. Automate it or accept the manual tax.