Open enough different project folders in VS Code over a few years, and you accumulate something most people never notice: a dedicated folder of saved state for every single one of them, most of which you will never open again. It's not a cache in the traditional sense — nothing here speeds up a rebuild — but it is disk space tied to workspaces you may have long since deleted from your Mac entirely.

What workspaceStorage actually is

VS Code stores per-workspace state at ~/Library/Application Support/Code/User/workspaceStorage/, with one subfolder per workspace, named with a hash derived from that workspace's path. "Workspace" here means any folder (or multi-root workspace file) you've opened directly in VS Code — every project, every one-off folder you glanced at once, every temporary clone you opened to review a pull request.

Inside each workspace's folder, you'll typically find:

  • state.vscdb — a SQLite database holding editor state specific to that workspace: which files were open, cursor positions, panel layout, recently used commands.
  • Extension-specific subfolders — many extensions store their own per-workspace data here rather than globally, since some state (a language server's index, a linter's cache, a Git extension's tracked branch state) only makes sense scoped to one project.

None of this is your actual source code or settings — it's VS Code's memory of how you last had a specific workspace arranged, plus whatever extensions decided was worth remembering per-project.

Why it never shrinks on its own

VS Code creates a new entry every time you open a folder that doesn't already have one, and it does not automatically delete entries for workspaces you haven't opened in years, or workspaces whose original folder no longer exists on disk at all. If you clone a repository temporarily to review something, open it in VS Code, then delete the clone a day later, the workspaceStorage entry for that now-nonexistent folder sticks around indefinitely.

For most individual developers this folder stays modest — a few hundred megabytes at most, since each workspace's own state is small. Where it becomes worth clearing is less about total size and more about clutter: hundreds of entries for workspaces that no longer exist, some tied to extensions that wrote unexpectedly large amounts of per-workspace data (certain language server or linting extensions have been known to cache substantial index data per project).

Check the overall size and the count of entries:

du -sh ~/Library/Application\ Support/Code/User/workspaceStorage
ls ~/Library/Application\ Support/Code/User/workspaceStorage | wc -l

A count in the hundreds for someone who has used VS Code for a few years is entirely normal.

Clearing it safely

VS Code rebuilds a fresh entry automatically the next time you open a workspace that had one deleted — you just lose the remembered editor layout and any extension-specific per-workspace cache for that folder, none of which affects your actual project files.

rm -rf ~/Library/Application\ Support/Code/User/workspaceStorage/*

removes everything. The next time you open any project, VS Code creates a fresh entry and most extensions rebuild whatever per-workspace index they need.

If you'd rather be selective, VS Code's own command palette has a related tool:

Developer: Delete Corrupted Workspace Storage (in the command palette, Cmd+Shift+P) — this specifically targets entries that VS Code has detected are corrupted or orphaned (typically pointing at workspace paths that no longer exist), which is a safer starting point than nuking everything if you only want to remove genuinely dead entries.

The related and often larger globalStorage folder

Sitting alongside workspaceStorage is ~/Library/Application Support/Code/User/globalStorage/, which holds extension data that isn't scoped to a specific workspace — settings sync state, extension-specific global caches, and in some cases substantial data for extensions that maintain their own large local databases (some AI coding assistants and language-specific extensions fall into this category). This folder is worth checking alongside workspaceStorage, since it can independently grow large depending on which extensions you have installed and how they're configured.

du -sh ~/Library/Application\ Support/Code/User/globalStorage/*

will show you per-extension size, which is often the more actionable breakdown if one particular extension turns out to be the actual space consumer.

Extensions themselves are a separate, usually larger cost

It's worth distinguishing all of the above from ~/.vscode/extensions, where the extensions themselves are installed. This folder tends to be larger than either storage folder, especially if you've installed and later disabled extensions without uninstalling them — a disabled extension still occupies its full install size until you remove it explicitly through the Extensions panel.

Remote and container-based development multiplies this again

If you use VS Code's Remote - SSH, Dev Containers, or WSL extensions to work on codebases that live somewhere other than your Mac's own filesystem, be aware that each of those contexts maintains its own separate workspaceStorage and extension state — on the remote host or inside the container, not inside ~/Library/Application Support/Code on your Mac at all. What you see locally in this folder only reflects workspaces you've opened directly on your local filesystem; a project you've only ever opened through Remote - SSH lives in an entirely separate storage location on that remote machine, invisible from the Mac side and unaffected by anything covered in this article.

This matters mainly for expectation-setting: if you primarily do remote development and are surprised that your local workspaceStorage looks smaller than you'd expect, that's the reason — the bulk of your actual workspace state is sitting somewhere else entirely.

A practical routine

  1. Check the size and entry count of workspaceStorage and globalStorage.
  2. Run Developer: Delete Corrupted Workspace Storage from the command palette as a low-risk first pass.
  3. If size is still a concern, clear workspaceStorage entirely — the cost is only remembered editor layout per project, not your code or global settings.
  4. Check globalStorage per-extension for any outsized single contributor.
  5. Separately review ~/.vscode/extensions for installed-but-unused extensions and remove them through the Extensions panel rather than by deleting folders directly, so VS Code's extension registry stays consistent.

Where VolumeLens fits in

Editor state folders like workspaceStorage rarely cause a real disk space emergency on their own, but they're part of the long tail of small, forgotten folders that add up across ~/Library/Application Support over years of development work. VolumeLens maps that whole tail visually in one scan, so you can see whether it's actually worth your time before diving into individual extension folders. Download the free version to see your own Application Support footprint.