Roomy
Guide

Why Cursor uses so much disk space on macOS

Cursor is a VS Code fork with an Electron shell and an AI layer on top. All three keep their own caches, and none of them clean up after themselves. On a machine used daily for a year, the Cursor folder alone can pass 15 GB.

Applies to Cursor on macOS 13 and later. Last reviewed October 2026.

Short answer. Cursor's data lives in ~/Library/Application Support/Cursor. The Cache, Code Cache, GPUCache, CachedData and logs folders are safe to delete once Cursor is closed. User/workspaceStorage and User/History hold per-project state and can be pruned for projects you no longer have. User/globalStorage holds your settings and chat history, so leave it alone.

Find out how much Cursor is using

Open Terminal and run:

du -sh ~/Library/Application\ Support/Cursor
du -sh ~/Library/Application\ Support/Cursor/* | sort -rh | head
du -sh ~/.cursor

The second command lists the subfolders largest first. On most machines the top entries are User, WebStorage and CachedData.

Where Cursor stores its data

FolderWhat it holdsDelete?
~/Library/Application Support/Cursor/Cache
…/Code Cache
…/GPUCache
…/DawnWebGPUCache
Chromium browser caches for the Electron shell. Rebuilt automatically. Safe
…/Cursor/CachedData Compiled JavaScript bytecode for the editor and extensions, one copy per Cursor version you have run. Safe
…/Cursor/WebStorage IndexedDB and local storage for the editor's web views. Can hold several GB after long use. Review
…/Cursor/User/workspaceStorage Per-workspace state: open editors, search history, extension data. One folder per project you have opened, including projects you deleted long ago. Review
…/Cursor/User/History Local file history, the "Timeline" view. Old snapshots of every file you have edited. Review
…/Cursor/User/globalStorage Extension state and the SQLite database that holds your Chat and Composer history. Keep
…/Cursor/logs Session logs. Small individually, never pruned. Safe
~/.cursor/extensions Installed extensions. Deleting them means reinstalling. Keep
Codebase indexing in Cursor happens on Cursor's servers, so there is no large local embeddings index to delete. The local footprint is almost entirely caches and per-workspace state.

Clean up by hand

Quit Cursor completely first. Then remove the always-safe caches:

cd ~/Library/Application\ Support/Cursor
rm -rf Cache "Code Cache" GPUCache DawnWebGPUCache CachedData logs

For workspaceStorage, each subfolder contains a workspace.json that points at the project it belongs to. Folders whose project no longer exists are safe to remove. Doing this by hand across dozens of folders is tedious, which is the part a tool should do for you.

What not to do

  • Do not delete User/globalStorage or User/settings.json. That is your settings, keybindings and chat history.
  • Do not clear caches while Cursor is running. It may write partially and corrupt the next launch.

Common questions

Where does Cursor store its data on macOS?

In ~/Library/Application Support/Cursor (caches, CachedData, WebStorage, User/workspaceStorage, User/History, User/globalStorage, logs) and ~/.cursor/extensions.

Which Cursor folders are safe to delete?

Cache, Code Cache, GPUCache, DawnWebGPUCache, CachedData and logs are rebuilt automatically. Quit Cursor first. Do not delete User/globalStorage or settings.json: they hold your settings, keybindings and chat history.

Does Cursor keep a local codebase index?

No. Codebase indexing happens on Cursor's servers, so the local footprint is caches and per-workspace state rather than an embeddings index.

Or let Roomy do it

Roomy scans Cursor, Claude, Windsurf and other AI editors alongside your project folders. It shows each cache with its size and a safety tier, keeps your settings and chat history out of the selection, and moves what you confirm to the Trash. It also finds the node_modules in every project you spun up and forgot.

Scan your Mac free with Roomy

Related: Where Claude Code stores its data · Where Ollama stores models

Home · Roomy for AI tools · Documentation · Privacy · Cookie preferences