VS Code, Cursor and JetBrains: The IDE Caches Nobody Checks

Xcode gets blamed for a full disk because DerivedData is famous. Your editor is doing the same thing quietly, and because everyone assumes “it’s just a text editor,” nobody ever checks.

du -sh ~/Library/Application\ Support/Code
du -sh ~/Library/Caches/JetBrains/*

Ten to thirty gigabytes across your installed editors is routine if you have used them for more than a year and never once cleared anything.

VS Code and Cursor (same architecture, same problem)

Cursor is a VS Code fork, so it hoards in the same places, one directory over:

# VS Code
du -sh ~/Library/Application\ Support/Code/CachedData
du -sh ~/Library/Application\ Support/Code/User/workspaceStorage
du -sh ~/Library/Application\ Support/Code/CachedExtensionVSIXs

# Cursor
du -sh ~/Library/Application\ Support/Cursor/CachedData
du -sh ~/Library/Application\ Support/Cursor/User/workspaceStorage

CachedData is precompiled V8 bytecode for the extensions you run. Regenerable, safe to delete outright, rebuilds silently on next launch.

workspaceStorage is the one that actually grows without bound: a subfolder per project you have ever opened, holding extension state, search history, and — if you use GitHub Copilot, GitLab Duo, or a similar AI extension — chat history and embeddings cache for that project. Folders for projects you deleted from disk years ago are still sitting in here. Safe to delete the ones whose project no longer exists; the editor recreates what it needs for projects you still open.

# Rank workspaceStorage by size, largest first
du -sh ~/Library/Application\ Support/Code/User/workspaceStorage/* | sort -hr

Each folder is named after a hash, not the project — open workspace.json inside it to see which path it belongs to before deleting.

CachedExtensionVSIXs holds the actual .vsix installer files for every extension version you’ve ever had installed, including old versions you upgraded past. Pure waste. Delete freely.

JetBrains (IntelliJ, WebStorm, PyCharm, GoLand, Android Studio)

JetBrains IDEs write into a versioned cache directory per major release, and — this is the part that surprises people — they never clean up after an upgrade:

ls ~/Library/Caches/JetBrains/
# IntelliJIdea2024.1  IntelliJIdea2024.2  IntelliJIdea2024.3  WebStorm2024.1  ...

Every version you have ever run left its full cache and index behind, forever, even though you now only use the newest one. This is frequently the single largest chunk of JetBrains disk usage and the easiest to reclaim:

# Delete every JetBrains cache folder except your current version
ls -d ~/Library/Caches/JetBrains/*/ | grep -v "$(ls -t ~/Library/Caches/JetBrains | head -1)"
# review the list, then re-run with rm -rf appended

Within the current version’s folder, caches/ holds the project index (safe — full re-index on next open, a few minutes for a large project) and plugins-sandbox/ holds test data if you develop plugins (usually safe unless you’re actively debugging a plugin).

Logs live separately and are equally safe to clear:

du -sh ~/Library/Logs/JetBrains/*
rm -rf ~/Library/Logs/JetBrains/*/

The one folder to leave alone in both

~/Library/Application Support/Code/User/settings.json, keybindings.json, and your installed extensions list are not cache — they’re your actual configuration. They live next to workspaceStorage but are a fraction of the size and are exactly what you’d lose if you deleted the whole User directory instead of just workspaceStorage inside it. Same for JetBrains: ~/Library/Application Support/JetBrains/<product>/options/ holds your settings, separate from the Caches folder this article is about — different top-level directory entirely, so a rm -rf scoped to ~/Library/Caches/JetBrains can’t reach it, but it’s worth knowing the two are distinct so you never guess wrong under time pressure.

What it adds up to

On a machine that’s run three JetBrains products and VS Code for two years, 15–25 GB across stale version caches and dead workspace storage is typical — and every byte of it regenerates. The commands above are free and they work.

DevCruft, a free Mac app for developers that’s still in development, is being designed to find every editor’s cache and flag which workspaceStorage entries point at projects that no longer exist on disk, so you’re not opening workspace.json files by hand to check. Join the waitlist to hear when it’s ready.

For every other developer cache eating your disk, see the full storage guide.