Bun Install Cache on Mac: Safe to Delete?
Medium riskPackage managers & build toolsUpdated
- Location
~/.bun/install/cache
- Risk level
- Medium riskSafe to remove, but the tool that owns it re-downloads or rebuilds it on next use, which costs time and bandwidth. Listed, never pre-selected.
- Selected by default
- No — you choose whether to include it
- What Freshist does
- Moves the selected items to the Trash, so you can undo. Nothing is deleted outright.
- In the app
- Clean → Bun Cache — “Package cache — future bun installs re-download packages.”
From Freshist's own cleaning rules — the same catalog the app uses.
What lives in the Bun cache
When bun install fetches a package from the npm registry, it unpacks it into a global store first: ~/.bun/install/cache/<name>@<version>, according to the Bun install docs. Every project on your Mac then installs from that store instead of the network. That's a large part of why a second bun install of the same dependency tree is close to instant.
The cache also holds registry metadata (package manifests) so Bun can resolve versions without asking the registry each time.
Why it grows
Bun never deletes old versions from the store on its own. Each new version of each dependency in each project adds another folder. If you try frameworks, bump dependencies often, or have many repos with slightly different lockfiles, the store fills up with versions that nothing uses any more. A few hundred megabytes is normal after light use; heavy monorepo work can push it into gigabytes.
What breaks, and what doesn't
On macOS Bun installs packages into node_modules with clonefile, which creates an independent copy-on-write copy. So deleting the cache doesn't pull files out from under existing projects.
| After clearing | Result |
|---|---|
Existing node_modules folders | Keep working unchanged |
Next bun install | Downloads every package that isn't in the cache, so it's slower |
| Offline installs | Fail until the packages are fetched again |
bun.lock, package.json, global tools in ~/.bun | Not touched |
You pay for it in bandwidth and in the time the next install takes, and that is all.
Find the cache and its size
Run these from any folder with a package.json:
bun pm cache # prints the cache folder path
du -sh "$(bun pm cache)" # total size
ls ~/.bun/install/cache | head # sample of cached package@version folders
If you set BUN_INSTALL_CACHE_DIR, bun pm cache shows that custom path instead of the default.
Clear it with Bun's own command
bun pm cache rm
That's the documented way to empty the store. The Bun docs also list rm -rf ~/.bun/install/cache as an alternative; it does the same thing, but the built-in command respects a custom cache location, so prefer it.
Close any running bun install first. To point a single install at a different cache folder instead, bun install --cache-dir <path> does that for one run.
Should you clear it at all?
Keep the cache if you're about to work offline or on a slow connection, or if you switch between many projects that share the same dependencies. Clearing it every week buys nothing, since the store fills right back up. Clear it when you've finished a project or stopped using a set of frameworks.
Bun isn't the only package manager keeping its own copy of the npm registry. If you also use npm or pnpm, their stores are separate: see the npm cache and pnpm store guides, or the overview in developer caches on Mac.
Sources
Frequently asked questions
Will my projects break if I clear the Bun cache?
No. On macOS Bun copies packages into each project's node_modules using clonefile, so the files there are independent of the cache. Existing installs keep working; only the next install has to download again.
Does bun pm cache rm delete bun itself or globally installed tools?
No. The Bun binary lives in ~/.bun/bin and global packages in ~/.bun/install/global. The cache command only empties ~/.bun/install/cache.
Can I put the cache somewhere else?
Yes. Set the dir option under [install.cache] in bunfig.toml (or the BUN_INSTALL_CACHE_DIR environment variable), and Bun stores its cache there instead.