Cursor and VS Code eating disk space: workspaceStorage and state.vscdb

Part of: Mac disk cleanup for developers: every cache, what it costs to rebuild (Developers)

Cursor and VS Code keep per-project data in a hidden folder, and over time it can get large. The two places to look are the workspaceStorage folder, which has one subfolder per project you opened, and the state.vscdb database files in it. Deleting them does not touch your code, but you can lose editor state such as chat history.

Both editors share the same base, so their folder layout is probably similar. This article gives the layout as we understand it and tells you how to check on your Mac, because the exact size and content depend on your version and extensions. Only the VS Code settings path is documented by the vendor (see the source below); everything else about the folder layout here is UNVERIFIED.

Where to look

The editor data lives in ~/Library/Application Support. Under it, Cursor uses a Cursor folder, and VS Code uses a Code folder. Inside each, User holds your data. Check what exists on your Mac:

ls ~/Library/Application\ Support | grep -i "cursor\|code"

Then list sizes inside the folder that appears:

du -sh ~/Library/Application\ Support/Cursor/User/* | sort -h

Swap Cursor for Code for VS Code. On the Mac used to check this article, neither editor was installed, so those folders did not exist and the sizes below are not measured. This article describes the layout in general terms and it is UNVERIFIED on a real install. Look at your own numbers before acting.

Source: the VS Code settings page, code.visualstudio.com/docs/editor/settings, accessed 2026-10-05, gives the macOS user settings path as $HOME/Library/Application Support/Code/User/settings.json. That page does not mention workspaceStorage or state.vscdb, and the Cursor documentation we checked (cursor.com/docs, accessed 2026-10-05) does not state where Cursor keeps its data. The Cursor folder name, workspaceStorage, state.vscdb and the cache and log folders below are therefore UNVERIFIED.

What the main folders are

• User/workspaceStorage: one subfolder per workspace, a workspace being a folder or project you opened. Each holds a state.vscdb file and other per-project data, such as search indexes and extension data.
• User/globalStorage: data shared across projects, including a global state.vscdb and storage used by extensions.
• Cache and CachedData: temporary data the editor can rebuild, including compiled code caches.
• logs: log files.

Why they get large

Forum threads describe users who found tens of gigabytes or more here. The usual cause is one oversized state.vscdb file or a few workspaces that accumulated a lot of extension or chat data. Old workspaces stay on disk even after you delete the project, because the editor does not clean them up.

Sort by size and look at the largest few items. Most of the space is almost always in a handful of files, not in thousands of small ones.

Safe, risky, never

• Probably safe (UNVERIFIED): Cache, CachedData and logs. We expect the editor to recreate them, but we have not confirmed it on a real install. Cost: a slightly slower first start.
• Risky (UNVERIFIED): workspaceStorage entries, and the state.vscdb files. Reports suggest they hold per-project state such as open tabs, and in some editors chat history and extension data. Removing them may reset that state. Possible cost: lost history, not lost code.
• Never: do not delete User/settings.json, keybindings.json or your snippets folder. They are your own configuration, not a cache. Do not delete a database file while the editor is open.

How to reduce it

1. Quit the editor completely, not just the window.
2. Sort the sizes with the command above and find the largest items.
3. Start with the likely-safe ones (UNVERIFIED): caches and logs.
4. For workspaceStorage, remove only subfolders for projects you no longer use. A subfolder name is a hash, so it does not tell you which project it belongs to. Look inside for a small file that names the folder, and do not guess.
5. Move what you remove to the Trash and empty it. See why the Trash does not free space.
6. Start the editor and check that your settings and projects load.

If you rely on chat history in Cursor, export what you need first. We could not check on this Mac how your version stores it.

Extensions

Extensions are installed in a hidden folder in your home folder, such as ~/.cursor or ~/.vscode, and can be large. Remove extensions you do not use from inside the editor. That is cleaner than deleting folders.

For other editors, see JetBrains IDE caches. For the wider picture of Library data, see what is safe to delete in Library/Caches and app leftovers. The developer map is in the developer cleanup guide.

Worked example: find the one big file

Say your disk is fuller than it should be and you use Cursor. Do this in order:

1. Run ls ~/Library/Application\ Support | grep -i "cursor\|code" to see whether the folder exists.
2. List what is large: du -sh ~/Library/Application\ Support/Cursor/User/* | sort -h. The last line is the largest.
3. If it is workspaceStorage, go one level deeper with the same command on that folder. Look at the biggest few subfolders.
4. Open a subfolder and check which project it names. If you cannot tell, leave it.

This article’s author has no Cursor or VS Code folder on the Mac used for checking, so these steps are UNVERIFIED on a real install. The commands only read, so running them is safe.

Reduce the cause, not only the size

If one file grows again after you remove it, find out what writes to it. Extensions that index your code, and chat history, are the usual suspects. Check each extension’s settings for a cache or index size option. Turning off an extension you do not use stops the growth at the source.

If something goes wrong

• The editor opens with no tabs or no history for a project. You removed its workspaceStorage entry. Your code is untouched. Open the folder again and the editor makes a new entry.
• Settings or key bindings are missing. Restore them from a backup if you have one. Check this before you delete anything in User.
• The editor will not start after a delete. Quit it fully and start it again. If it still fails, put the item back from the Trash.
• The folder is large again within weeks. The cause is still running. See the section above.

When not to clean

Do not clear a workspace entry for a project you are working on this week. The open tabs, the search index and some extension data are in it. The next start will be slower and you will rebuild that state by hand. Old projects are the right target.

See sizes in a scan

DiskJoy is our product. Its scan reads your disk and shows how large folders such as these are, read-only. Cleanup is not built yet, so DiskJoy does not delete editor data today.