Where VS Code hides the gigabytes
Everything VS Code stores lives under %APPDATA%\Code, and four subfolders do most of the hoarding. User\workspaceStorage keeps a directory of state for every folder you have ever opened — deleted projects included — and nothing prunes it automatically. Cache, Code Cache and GPUCache are Chromium's usual suspects, rebuilt constantly and safe to wipe at any moment. logs writes a fresh folder for every session you have ever started, and CachedExtensionVSIXs keeps the installers of extension updates long after they were needed.
Add %USERPROFILE%\.vscode\extensions, where orphaned versions of extensions sometimes survive updates, and a heavy editor install passes 5 GB without ever showing you a warning. None of these locations hold your settings or keybindings — those live in User\settings.json and are untouched by any cache purge.
- %APPDATA%\Code\User\workspaceStorage — per-project state for every folder ever opened; the single biggest hoard on old machines
- %APPDATA%\Code\Cache, Code Cache, GPUCache — Chromium caches, safe to delete, rebuilt on next launch
- %APPDATA%\Code\logs — a folder per session; nothing ever prunes it
- %APPDATA%\Code\CachedExtensionVSIXs — downloaded extension installers kept after updates
- %USERPROFILE%\.vscode\extensions — orphaned old versions of extensions after updates
- Local History .history folders — inside your projects, if the extension is enabled; old snapshots pile up in the repo
Extensions are the real performance tax
Storage is the smaller half of the problem. Every extension loads into a shared extension host process, and heavyweights — language servers like Pylance, C/C++ or the TypeScript server, plus linters and themes — each consume their own hundreds of megabytes of RAM whether or not you use them. Startup stretches too: the Developer: Startup Performance command shows exactly which extensions cost how many milliseconds, and the numbers routinely surprise people with sixty-extension setups.
Audit with code --list-extensions, then uninstall instead of disable — a disabled extension still sits on disk and sometimes still loads. The Profiles feature is the honest fix for mono-installations: a lean default profile, with separate profiles for Python, writing and terminal-only work, each carrying only the extensions that profile needs.
A cleanup routine that sticks
Twice a year is plenty: close VS Code, delete the contents of Cache, Code Cache, GPUCache, logs and CachedExtensionVSIXs, and clear workspaceStorage entirely — you lose per-workspace state like task history, not your settings. Nothing gets reinstalled or reset. The editor rebuilds what it needs on the next launch, and the first start after the purge is slower by seconds, once.
To keep it lean, treat extensions like installed programs, not like stickers: every one needs a current reason to exist. And before migrating to a new machine, run the purge first — otherwise you copy three years of workspaceStorage for projects that died in 2023.
Questions and Answers
Is it safe to delete VS Code's workspaceStorage folder?
Yes — VS Code recreates entries for folders as you open them; you only lose per-workspace state such as task history and UI layout, not settings or extensions.
How do I find out which VS Code extensions slow down startup?
Run the Developer: Startup Performance command from the Command Palette; it breaks startup time down per extension and per phase, so the offenders are named, not guessed.
Know what is included before you buy.
The one-time 30-minute trial covers core tools. PRO-labelled features stay locked until a paid license is activated.
Read next
Write to us: [email protected]