If you have noticed your Mac's storage slowly disappearing and VS Code is your daily driver, the editor is almost certainly a culprit. The VS Code cache taking up space on Mac is a surprisingly common issue that rarely appears in disk-cleanup guides — most articles cover Xcode's derived data or Simulator runtimes, but VS Code quietly accumulates gigabytes of its own hidden data over time. This guide walks through every folder involved, what is safe to delete, what to leave alone, and how to clean it all without breaking your editor.
Why VS Code Gets So Large on macOS
VS Code is built on Electron, which means it maintains its own Chromium-based renderer process. On top of that, every extension you install, every workspace you open, and every language server that spins up leaves traces on disk. There are four main areas to know about:
- CachedData — compiled V8 bytecode for the extension host and renderer. Regenerated automatically when VS Code updates.
- workspaceStorage — per-workspace SQLite databases, extension state, and search indexes. Grows unboundedly as you open new projects.
- Extension folders — the actual installed extension bundles, including bundled language servers, node_modules trees, and grammar files.
- Logs and crash reports — rolling log files written by the extension host and each language server.
Where VS Code Stores Its Data on Mac
VS Code splits its data across three separate macOS locations depending on what kind of data it is:
| Folder | Typical path | What lives there |
|---|---|---|
| Application cache | ~/Library/Caches/com.microsoft.VSCode |
Electron / Chromium page cache, GPU cache |
| CachedData | ~/Library/Application Support/Code/CachedData |
Compiled V8 bytecode (one folder per VS Code version) |
| workspaceStorage | ~/Library/Application Support/Code/User/workspaceStorage |
Per-project extension state, search index, SQLite DBs |
| Extensions | ~/.vscode/extensions |
Installed extension bundles |
| Logs | ~/Library/Application Support/Code/logs |
Extension host and language server logs |
The workspaceStorage folder is usually the largest offender for developers who hop between many projects. Each workspace gets a hashed folder, and VS Code never prunes stale entries for projects you no longer have on disk.
How to Check How Much Space VS Code Is Actually Using
Before deleting anything, see what you are dealing with. Open Terminal and run:
du -sh ~/Library/Caches/com.microsoft.VSCode \
~/Library/Application\ Support/Code/CachedData \
~/Library/Application\ Support/Code/User/workspaceStorage \
~/.vscode/extensions \
~/Library/Application\ Support/Code/logs 2>/dev/null
This prints sizes for each folder in human-readable form. It is common to see workspaceStorage alone exceeding 1–2 GB on a machine that has been in use for a year or more.
What Is Safe to Delete (and What Is Not)
Safe to delete while VS Code is closed
~/Library/Caches/com.microsoft.VSCode— Chromium page and GPU cache. Fully regenerated on next launch. No data loss.~/Library/Application Support/Code/CachedData— Old V8 bytecode folders from previous VS Code versions accumulate here. VS Code only uses the folder matching its current version; older subdirectories are safe to remove. Deleting the current version's folder is also safe — it will be rebuilt, at the cost of a slightly slower first launch.~/Library/Application Support/Code/logs— Log files. Safe to clear; new logs are created on next run.- Stale
workspaceStorageentries — Any hashed subfolder whose corresponding project no longer exists on disk. These are orphaned and will never be read again, but VS Code does not clean them automatically.
Think before deleting
~/Library/Application Support/Code/User/workspaceStorage(as a whole) — Deleting the entire directory removes extension state for all currently open and recent projects. You will lose things like the state of pinned terminals, extension-specific per-project settings, and search history. VS Code will not crash, but some extensions (GitLens history views, todo-tree state, etc.) will reset.~/.vscode/extensions— Do not delete this unless you intend to reinstall all your extensions. Removing individual extension folders for extensions you have already uninstalled through the VS Code UI is fine.
How to Clear the VS Code Cache on Mac (Step by Step)
- Quit VS Code completely. Check the Dock and use Cmd+Q; do not just close the window.
- Clear the Chromium cache:
rm -rf ~/Library/Caches/com.microsoft.VSCode - Remove old CachedData versions. First check what is in there — only delete subdirectories that do not match your current VS Code version number:
Then remove outdated ones (replacels ~/Library/Application\ Support/Code/CachedData1.89.0with the old version you want to drop):rm -rf ~/Library/Application\ Support/Code/CachedData/1.89.0 - Prune stale workspaceStorage entries. The safest approach is to let VS Code's built-in command handle this: open VS Code, press Cmd+Shift+P, and run Developer: Open Workbench Storage Folder to inspect entries. For a bulk clean of orphaned folders, quit VS Code and run:
Note: this removes state for all workspaces, not just orphaned ones. Be sure this trade-off is acceptable before running it.rm -rf ~/Library/Application\ Support/Code/User/workspaceStorage - Clear log files:
rm -rf ~/Library/Application\ Support/Code/logs - Relaunch VS Code. All cleared folders are recreated automatically. Expect a slightly slower first load as bytecode is recompiled.
Clearing the VS Code Cache with Crumb
If you would rather not navigate hidden Library folders manually, Crumb finds VS Code's Application Support and cache directories as part of its whole-Mac scan. The Visualize tab shows the largest items on disk — including the Application Support/Code subtree — so you can see exactly what is taking space before touching anything. The Uninstall tab also surfaces leftover files from any VS Code version you have previously removed. If you are unsure whether a particular folder is safe to delete, Crumb's built-in AI will explain what the folder is and rate the risk of removing it before you commit. Cleaning is permanent, so having that safety check is worthwhile.
You can download Crumb and run one cleanup free to see what it finds.
Keeping VS Code Lean Over Time
- Uninstall extensions you no longer use. Each extension can add tens to hundreds of megabytes, especially those that bundle a full language server (Pylance, rust-analyzer, Copilot).
- Use VS Code's Remote extension. If you work in Docker or SSH targets, the extension host — and its disk footprint — lives on the remote machine, not your Mac.
- Update VS Code regularly. Each update replaces the current CachedData folder, automatically cleaning the old one. Staying on a stale version means old and new bytecode folders both accumulate.
- Run the workspaceStorage prune periodically. A quarterly wipe of that folder is low-risk and keeps storage in check.
Conclusion
VS Code's hidden caches, compiled bytecode, and workspaceStorage entries can collectively consume several gigabytes on a Mac that has seen regular development use — and none of it is visible in a standard storage check. The good news is that the Application cache, old CachedData versions, and stale workspace entries are all safe to delete with VS Code closed, and the editor rebuilds what it needs on the next launch. Take five minutes to run through the steps above and you will likely reclaim more space than most other cleanup tasks combined.