How to free up disk space on a Mac: a developer's guide

A developer's Mac fills up differently from anyone else's. The photos and the downloads folder are rarely the problem. The problem is that every project you have ever built left several gigabytes behind, every package manager kept a copy of everything it downloaded, and every application on the machine has been writing to its own cache folder for years. Almost all of it regenerates. Very little of it needs to be there.

Where the space actually goes

Before deleting anything, it helps to know which categories are worth your attention. These are the ones that reliably run to gigabytes, and what each one costs you if you remove it:

What	Why it exists	How it comes back
DerivedData	Xcode build intermediates, indexes, module caches	Regenerated on the next build
node_modules	Installed dependencies, one copy per project	npm install
.next / .turbo / dist	Framework and bundler build output	Next build
target	Rust compilation artifacts, per crate	cargo build
~/.npm/_cacache	Every package tarball npm has downloaded	Re-fetched from the registry
~/Library/Caches	One folder per installed app, decades deep	Rebuilt by each app on demand
ms-playwright	A full browser set per Playwright version	Re-downloaded on next install
~/Library/Logs	Per-app log folders that nothing rotates	Written fresh

The pattern is consistent: everything on that list is a cache or a build product. None of it is your work, and none of it is irreplaceable — the only cost of deleting it is time, paid once, the next time you build or install.

Finding it without guessing

macOS gives you About This Mac → Storage, which is close to useless for this: it buckets almost everything a developer cares about into “System Data” and offers no way to look inside. The usual next step is a manual tour with du -sh *, which works but takes an afternoon and misses anything outside the directory you happened to be standing in.

The alternative is a tool that already knows where these things live. purge is a command-line scanner for exactly this: one pass over your home directory, everything grouped and sized, nothing deleted until you say so.

npm i -g purge-cli
purge

It requires macOS and Node 22.18 or later, has zero runtime dependencies, makes no network calls, and sends no telemetry. The scan itself is read-only — you get a full picture of what is reclaimable before any decision is required.

What is safe to delete, and what is not

Safe, in almost every case

Xcode DerivedData — build intermediates and indexes. Regenerated on the next build; deleting it is a standard fix for stale-build weirdness.
node_modules in idle projects — fully reproducible from a lockfile. Weigh it by how long the project has sat untouched.
Build output — .next, .turbo, dist, build, cargo target, Python virtual environments.
Package-manager caches — npm, bun, Homebrew, Gradle, Playwright browsers, Electron distributions. These are download caches; clearing one means a re-download, nothing more.
Application and log caches — every app rebuilds its cache folder on demand, and nothing rotates ~/Library/Logs for you.

Not safe, whatever a cleaner tells you

Anything inside iCloud Drive, Dropbox, Google Drive or OneDrive — a deletion there syncs to every other machine you own.
Browser profiles — passwords, bookmarks, history and open sessions live next to the caches, and the distinction is not obvious from the folder names.
Coding-agent session history — ~/.claude/projects, ~/.codex/sessions and their equivalents. Resume and rewind stop working without them.
Xcode Archives — these are shipped builds, not build junk.
Anything tracked in git — a committed dist/ looks exactly like build output and is not.

This distinction is the whole reason purge exists as a review screen rather than a single command. It refuses to delete the second list outright, and shows the genuinely ambiguous cases — git-tracked, cloud-synced, ML model caches, agent history — unchecked with a warning next to them, so the default action is always the conservative one.

Clearing it in one pass

Running purge with no arguments scans everything and drops you into a keyboard checklist. Rows are grouped, sized and sorted, and the footer keeps a running total of what you have selected:

space toggles an item, or a whole group from its header
tab hops to the next checkbox, skipping headers
/ filters by path, a selects all or none
enter deletes what is checked; q leaves without touching anything

To look at one category only, name the groups: purge builds xcode. To get machine-readable output instead of the review screen, use purge --json.

Keeping directories permanently off-limits

Client work, a directory you never want a cleaner to see, a build cache you are deliberately keeping warm — put a glob in ~/.purgerc and it is never shown and never deleted:

{
  "keep": ["**/work/**", "~/Developer/client-project/**"],
  "staleDays": 90,
  "minSize": 25
}

staleDays sets how long a build directory must sit untouched before it is offered at all, and minSize is the megabyte floor below which items are not listed — both exist to keep the review screen short enough to actually read.

There is no undo — there is a record

Deletion is permanent, so purge writes a manifest of every run to ~/.purge/runs/: every path, its size, and when it went. If something you expected is missing a week later, purge history tells you whether it was this tool that took it.

Frequently asked questions

How do I free up disk space on a Mac as a developer?

Start with regenerable data rather than your own files. On a working developer Mac the largest reclaimable items are almost always Xcode DerivedData, node_modules directories in projects you are no longer building, framework build output such as .next, .turbo and dist, and package-manager caches for npm, bun, Homebrew and Playwright. Install purge with `npm i -g purge-cli` and run `purge`: it finds all of them in one scan, shows each one's size, and deletes only the rows you leave checked.

Is it safe to delete node_modules?

Yes, when the project has a lockfile committed. node_modules is entirely reproducible from package.json and your lockfile — `npm install` rebuilds it byte for byte. The only cost is the reinstall time the next time you work on that project, which is why purge flags directories by how long they have been idle instead of deleting them blindly.

Is it safe to delete Xcode DerivedData?

Yes. DerivedData holds intermediate build products, indexes and module caches that Xcode regenerates on the next build. Deleting it is a standard fix for stale-build problems, and it is frequently the single largest folder on an iOS developer's machine. Xcode Archives are a different thing — those are your shipped builds, and purge never deletes them.

Does purge have an undo?

No, and it does not pretend to. Deletion is real. What purge gives you instead is a precise record: every run writes a manifest to ~/.purge/runs/ listing every path, its size and when it went. Read it back with `purge history`, or `purge history --last --json` to pipe it somewhere.

How do I stop a cleaner from touching a specific directory?

Create ~/.purgerc and add a glob to its keep array — for example {"keep": ["**/work/**"]}. Anything matching is never shown in the review screen and never deleted. The same file sets staleDays, which controls how long a build directory must sit untouched before it is offered, and minSize, the megabyte floor below which items are not listed at all.

Is it safe to delete the npm cache?

Yes. ~/.npm/_cacache is a download cache: clearing it means the next install re-fetches packages from the registry rather than reading them locally. It commonly runs to several gigabytes on a machine that has been installing packages for a year or two. The same reasoning applies to Homebrew, bun, Playwright browsers and Electron distributions.

What should you never delete when cleaning a Mac?

Anything that is not regenerable: application settings and credentials, browser profiles containing passwords, bookmarks and history, installed editor extensions, coding-agent session history, Xcode Archives, and anything living inside iCloud Drive, Dropbox, Google Drive or OneDrive — deleting there propagates the deletion to your other machines. purge refuses to delete the first group outright, and shows the rest unchecked with a visible warning.

Try it

npm i -g purge-cli   # or: npx purge-cli
purge

MIT-licensed and open source — the source is on GitHub, the package is on npm, and the landing page shows the review screen in action.