Is It Safe to Clear the Composer Cache on a Mac? (~/.composer/cache)

Yes, it's safe to deleteDiskmack safety tier: Safe to clean

~/.composer/cache

Yes, you can clear the Composer cache on your Mac without breaking anything. The folder at ~/.composer/cache only holds copies of PHP packages Composer already downloaded, kept around so reinstalls skip the network. Your projects' vendor folders, your composer.json files, and your global Composer config are all untouched. The only cost is that the next composer install re-downloads whatever it needs.

What it is

Composer is PHP's dependency manager, and ~/.composer/cache is its download cache. Every time Composer fetches a package (a Laravel release, a Symfony component, a random utility library), it keeps a copy of the archive here. The next time any project on your Mac asks for that same version, Composer unzips the local copy instead of hitting Packagist or GitHub again. The folder exists purely to make installs faster and save bandwidth.

It grows because Composer's own housekeeping is minimal. A built-in garbage collector exists, but it runs only occasionally and by default lets an archive sit unused for six months before purging it. Update dependencies across a few projects and the cache accumulates a near-duplicate archive for every version you have pulled. On an active PHP developer's machine it commonly reaches several hundred megabytes, and if you install packages straight from git, the repository mirrors Composer also keeps here can push it past a gigabyte. If you have not run Composer in months, every byte of it is dead weight.

Is it safe to delete?

This is one of the safest deletes on a developer Mac. Nothing in ~/.composer/cache is original data. Installed dependencies live in each project's vendor folder, your lock files record the exact versions, and the cache is just a pile of downloaded archives that can all be fetched again. Delete the whole thing and every project keeps working exactly as before.

What you give up is speed, not safety. The next composer install or composer update in each project re-downloads the packages it needs, so it takes longer and uses your connection. On a decent connection that is a minor annoyance, not a problem. One thing to avoid: don't delete ~/.composer itself, only the cache folder inside it. The parent directory can hold your auth.json (Packagist and private repo tokens) and global config, and those do not come back on their own. Diskmack flags this folder automatically and deletes only the cache contents, leaving your Composer config alone.

How to check its size

In Finder: In Finder, choose Go > Go to Folder (or press Command-Shift-G), paste ~/.composer/cache and press Return. Select the folder, then press Command-I to see its size. If the folder doesn't exist, you either haven't used Composer or it's installed under a custom COMPOSER_HOME.

In Terminal:

du -sh ~/.composer/cache

How to clean it

In Finder, choose Go > Go to Folder (or press Command-Shift-G).
Type ~/.composer/cache and press Return.
Press Command-A to select everything inside the cache folder, then move it to the Trash. Leave the cache folder itself and the rest of ~/.composer in place.
Empty the Trash to actually reclaim the space.

If you have Composer on your PATH, running composer clear-cache in Terminal empties the same folder and is the tool's own way to do it. Either method gets the same result.

Will it come back?

Yes, it comes back, and that is by design. The moment you run composer install or composer update in any project, Composer starts caching downloads again. How fast it regrows depends on how many PHP projects you touch and how often you update dependencies: a single small project rebuilds a modest cache, while a busy freelancer juggling client codebases can be back to hundreds of megabytes within weeks. Clearing it is a recurring cleanup, not a one-time fix, so it's worth knowing the folder rather than treating this as a permanent win.

Common questions

Will clearing the Composer cache break my PHP projects?

No. Installed packages live in each project's vendor folder, which the cache does not touch. Your composer.json and composer.lock files are in your projects, not in the cache. After clearing, everything runs exactly as before; only the next install has to download packages again.

Should I delete the whole ~/.composer folder instead?

No, stick to the cache subfolder. ~/.composer can also contain auth.json with your Packagist or private repository tokens, plus global config and globally installed tools. Deleting those means re-entering credentials and reinstalling global packages. The disk space is almost entirely in the cache anyway.

Why is my Composer cache so large?

The cache is shared across every project on the machine, and each dependency update adds another almost-identical archive alongside the old one. Composer's garbage collection does prune old entries eventually, but it runs infrequently and its six-month default is generous, so the folder stays large between sweeps. A year of active PHP work can add up to hundreds of megabytes or more.

The folder isn't at ~/.composer/cache. Where else could it be?

If COMPOSER_HOME or COMPOSER_CACHE_DIR is set in your shell, Composer uses that location instead. Run composer config --global cache-dir in Terminal to see the exact path your setup uses, then check the size of that folder with du -sh.