Can I Delete the .ivy2 Folder on My Mac? Yes, and Here's Why

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

~/.ivy2

Yes, you can delete ~/.ivy2. It is the dependency cache used by Apache Ivy and sbt for Scala and other JVM builds, and everything in it gets re-downloaded the next time you run a build. Your project code, sbt itself, and your settings are untouched. The only real caveat: if you have ever run sbt publishLocal, those locally published artifacts live in ~/.ivy2/local and you would need to publish them again from source.

What it is

Apache Ivy is a dependency manager for the JVM, and for years it was the engine behind sbt, the standard build tool for Scala. Every time an Ivy-based build resolved a dependency, it downloaded the jar files and their metadata from repositories like Maven Central and stored them in ~/.ivy2/cache. The cache is shared across every project on your Mac, so it accumulates a copy of every version of every library any of your Scala or JVM projects has ever pulled in. It never prunes itself, which is how it quietly grows to several gigabytes on a machine that has seen real Scala work.

There is a good chance the folder is not even in active use anymore. Since sbt 1.3, dependency resolution defaults to Coursier, which keeps its own cache under ~/Library/Caches/Coursier, so on many Macs ~/.ivy2 is a leftover from older sbt versions or older projects. Ivy also shows up outside Scala: Apache Spark's --packages flag downloads jars into ~/.ivy2, and some Ant and Groovy setups use Ivy too. Whatever put it there, the contents are downloaded copies of publicly available libraries, not anything you wrote.

Is it safe to delete?

Deleting ~/.ivy2 is safe. The folder is a download cache: the next time you build a project that resolves dependencies through Ivy, the build tool notices the jars are missing, fetches them again from the original repositories, and carries on. The cost is bandwidth and a slower first build, usually a few minutes on a normal connection. If your projects have moved to Coursier or you no longer write Scala at all, there may be no rebuild cost whatsoever, because nothing will ever ask for those jars again. Diskmack identifies this folder automatically and cleans it the safe way.

The one subfolder worth a glance before you delete is ~/.ivy2/local. That is where sbt publishLocal puts artifacts you built and published on your own machine, typically so another local project can depend on them. Those are not downloadable from anywhere; they came from your own source code. Deleting them breaks nothing permanently, but any project that depends on them will fail to resolve until you run publishLocal again in the library's source project. If you have never used publishLocal, the folder is empty or absent and there is nothing to think about.

How to check its size

In Finder: In Finder, choose Go > Go to Folder (Shift-Command-G), type ~ and press Return to open your home folder. Press Command-Shift-Period to reveal hidden items, select the .ivy2 folder, and press Command-I. The Info window shows its total size.

In Terminal:

du -sh ~/.ivy2

How to clean it

Quit any terminal running an sbt build and any editor with Scala tooling active (Metals, IntelliJ with a Scala project open), so nothing repopulates the cache mid-delete.
If you use sbt publishLocal, check ~/.ivy2/local first. Anything in there needs to be re-published from its source project after the deletion.
In Finder, choose Go > Go to Folder (Shift-Command-G), type ~ and press Return, then press Command-Shift-Period to reveal hidden folders.
Select the .ivy2 folder and move it to the Trash (Command-Delete).
Empty the Trash to actually reclaim the space.
The next sbt or Spark run that needs those dependencies re-downloads them automatically.

There is no built-in command that clears this cache. sbt clean is a different thing entirely: it deletes one project's target directory, its compiled output, and never touches ~/.ivy2. Deleting the folder in Finder is the normal way to do this.

Will it come back?

Only if something still uses Ivy. If you run older sbt projects or use Spark's --packages flag, the folder refills with exactly the dependencies those builds resolve, growing again as versions update. But on Macs where every project has moved to sbt 1.3 or later with Coursier, ~/.ivy2 often never comes back at all after deletion, which makes it one of the more satisfying developer caches to clear. Check its size once or twice a year; if it is regrowing, some build on your machine is still resolving through Ivy.

Common questions

Will deleting ~/.ivy2 break my Scala projects?

No. Your source code, build definitions, and sbt installation are untouched. The next build re-resolves its dependencies and downloads the jars again from Maven Central or wherever they came from. You need a network connection for that first rebuild, and it takes a few extra minutes. That is the whole cost.

I don't write Scala. Why do I have a .ivy2 folder?

Other JVM tools use Ivy too. The most common culprit on modern Macs is Apache Spark: running spark-shell or spark-submit with the --packages flag downloads jars into ~/.ivy2. Some Ant and older Groovy or Grails setups also resolve through Ivy. If none of that rings a bell, the folder is almost certainly a leftover you can delete without a second thought.

Is ~/.ivy2 the same cache that Maven or Gradle use?

No. Maven keeps its repository in ~/.m2, and Gradle caches under ~/.gradle. Each JVM build tool maintains its own copy of downloaded dependencies, which is why a long-lived developer Mac often carries three or four of these folders, each holding gigabytes of largely overlapping jars. Each one is safe to clear on the same logic: it re-downloads what builds actually need.

Should I delete ~/.sbt as well while I'm at it?

Probably not. ~/.sbt holds sbt's own settings, global plugins, and boot files rather than downloaded dependencies, and it is usually small. Deleting it loses configuration rather than reclaiming meaningful space. The disk win is in ~/.ivy2 and, for newer setups, the Coursier cache at ~/Library/Caches/Coursier.