DiskmackDownload free

Is the VS Code Cache Folder Safe to Delete on Mac?

Yes, it's safe to deleteDiskmack safety tier: Safe to clean
~/Library/Application Support/Code/Cache~/Library/Application Support/Code/CachedData

Yes, you can delete VS Code's Cache and CachedData folders. Both are safe to remove, and VS Code rebuilds what it needs the next time it starts. Your settings, extensions, and projects live elsewhere and are not touched. Quit VS Code first, then clear both folders.

What it is

VS Code is an Electron app, which means it runs on a bundled copy of Chromium, and Chromium caches aggressively. The folder at ~/Library/Application Support/Code holds all of VS Code's per-user data. Inside it, Cache is where the editor's rendering engine stores cached resources for windows, webviews, and extension UI so they open faster on repeat visits. It fills up quietly the same way a browser cache does, and the editor never trims it back very hard.

CachedData is different and, honestly, the better cleanup target. It holds V8 compilation caches, precompiled JavaScript that lets the editor start faster, and it is keyed per VS Code version. Every time VS Code updates (roughly monthly), it creates a new subfolder for the new build. The folders for versions you no longer run are pure leftovers; nothing ever reads them again. Between the two folders you will often find hundreds of megabytes, and long-lived installs with lots of extensions can accumulate a gigabyte or more.

Is it safe to delete?

Yes. Nothing in Cache or CachedData is user data. Your settings and keybindings are in the User folder next door, your extensions are in ~/.vscode/extensions, and your actual code is wherever you saved it. Deleting these two folders costs you exactly one thing: the first launch afterward is a little slower while VS Code rebuilds its caches. After that, everything is back to normal.

The old version folders inside CachedData do not even come back. They belonged to builds of VS Code you no longer run, so that space is a permanent win, not a temporary one. The one rule that matters: quit VS Code before you delete anything, so the app is not writing to the folders while you empty them. Diskmack identifies both folders automatically and clears them the safe way, with the app closed.

How to check its size

In Finder: In Finder, choose Go > Go to Folder (or press Cmd+Shift+G), paste ~/Library/Application Support/Code and press Return. Select the Cache and CachedData folders, then press Cmd+Option+I to see their combined size.

In Terminal:

du -sh ~/"Library/Application Support/Code/Cache" ~/"Library/Application Support/Code/CachedData"

How to clean it

  1. Quit VS Code completely: press Cmd+Q in the app and confirm it is no longer running in the Dock.
  2. In Finder, press Cmd+Shift+G and go to ~/Library/Application Support/Code.
  3. Move the Cache folder to the Trash.
  4. Move the CachedData folder to the Trash as well. If you'd rather be selective, open it, sort by Date Modified, and delete every subfolder except the newest one, which belongs to the build you're running now.
  5. Empty the Trash, then relaunch VS Code. It rebuilds both folders on startup.

There is no built-in VS Code command that clears these folders, so Finder is the official method here. Deleting them while the app is running can recreate files mid-delete, so always quit first.

Will it come back?

Yes, both folders regrow, because caching is their job. Cache refills as you use the editor and tends to level off after a while. CachedData rebuilds a folder for your current version on the next launch, and every future VS Code update adds a new one while the old ones sit there as dead weight. Clearing them is not a one-time fix; it is more like emptying a browser cache, worth repeating every few months or whenever disk space gets tight.

Common questions

Will this delete my settings, extensions, or projects?

No. Settings, keybindings, and snippets live in ~/Library/Application Support/Code/User, extensions live in ~/.vscode/extensions, and your code stays wherever you saved it. Cache and CachedData contain nothing you configured and nothing you wrote.

What are the folders with long gibberish names inside CachedData?

Each one is named after a single VS Code build (the name is that build's commit id) and holds its V8 compilation caches. Only the folder for the build you're running now is ever read again. VS Code updates about once a month and never cleans up after itself here, so the rest are leftovers from builds you no longer run.

Can I also delete GPUCache and Code Cache in the same directory?

Those are the same kind of Chromium cache and rebuild on launch too. The same procedure applies: quit VS Code first, then move them to the Trash. They are usually smaller than Cache and CachedData, so the extra savings are modest.

Will VS Code be slower after I clear these?

Only the first launch, while the caches rebuild. After that it runs normally. If the editor had been acting up because of a stale or corrupted cache, clearing these folders sometimes fixes it as a side effect.

Related folders