Why are Cursor .pack files eating my Mac disk space?

"I had 72 .pack files over 1 GB, plus 306 between 500 MB and 1 GB." That receipt comes from the Cursor forum thread on .pack files eating disk space, filed by a developer who only noticed when his Mac's System Data bar passed 200 GB and macOS refused to download an update. It is not an outlier. Cursor .pack files compound silently because Cursor opens a fresh workspaceStorage entry for every project you ever opened, holds onto it forever, and historically had no size ceiling on the pack files inside.

What is a Cursor .pack file and why does it exist?

A Cursor .pack file is a Git-style packfile storing per-workspace edit history, local undo state, and the snapshots Cursor's "Restore Checkpoint" feature relies on.

The problem on disk is volume, not encoding. Cursor creates a fresh workspaceStorage subfolder the first time you open any project, and it never removes that subfolder when you stop using, delete, or uninstall anything. Every project you have ever opened still has an entry, and its .pack file keeps growing on each reopen. Stack 18 months of project switching and Cursor .pack files disk space stops being theoretical.

Where do Cursor .pack files live on a Mac?

One path holds everything that matters: ~/Library/Application Support/Cursor/User/workspaceStorage/. Inside is one subfolder per opened workspace, each named with an opaque hash. Cursor's UI offers no friendly mapping back to the project path.

ls ~/Library/Application\ Support/Cursor/User/workspaceStorage/

# Inside one workspace, you usually see:
# state.vscdb              SQLite, settings + history index
# *.pack                   the big ones
# *.idx                    pack index, small
# anysphere.cursor-*       per-extension subfolders

A clean Mac with a handful of projects has 5 to 10 entries totaling a few hundred MB. A dev who has cycled through client projects, OSS forks, and experiments for a year often has 80 to 200 entries summing to tens of GB, the heaviest five accounting for over half.

How big do Cursor .pack files actually get?

The forum thread above is the most-quoted public receipt, not the largest. Rough buckets:

The "heavy AI-assisted editing" row matters most. Every accepted or rejected suggestion lands a new entry in local history, that history goes into the .pack file, and the .pack file only knows how to grow.

How do you measure Cursor .pack files disk space before you touch anything?

Two commands answer the question. The first sizes every workspace, the second sorts every individual pack file by size.

# Total size of Cursor's workspaceStorage tree.
du -sh ~/Library/Application\ Support/Cursor/User/workspaceStorage

# Per-workspace breakdown, biggest at the bottom.
du -sh ~/Library/Application\ Support/Cursor/User/workspaceStorage/*/ 2>/dev/null | sort -h | tail -20

# Every .pack file across every workspace, biggest at the bottom.
du -sh ~/Library/Application\ Support/Cursor/User/workspaceStorage/*/*.pack 2>/dev/null | sort -h | tail -20

If the top-level du returns over 5 GB you have legacy bloat. A single .pack over 1 GB is the forum-thread case. Ten or more workspace hashes you have not touched in months is the cleanup target.

To map a workspace hash back to a project path, read the state.vscdb SQLite file in that folder:

# Decode one workspace hash to its project path. Replace <hash>.
sqlite3 ~/Library/Application\ Support/Cursor/User/workspaceStorage/<hash>/state.vscdb \
  "SELECT value FROM ItemTable WHERE key='memento/workbench.parts.editor';" 2>/dev/null | head -c 400

That returns a JSON blob with the last opened files, usually enough to identify the project.

Which Cursor .pack files are safe to delete?

Three classes of pack files live under workspaceStorage/, with different risk profiles.

Anything not opened in a month is dead storage, because Cursor's local history only matters while you are iterating. The active-workspace case is fine if you quit Cursor first, settings, extensions, login, synced rules, and the project's .cursor/ rules folder all live elsewhere and are untouched. Quitting Cursor before you start eliminates the third row entirely.

How do you clean Cursor .pack files step by step?

Five steps, none destructive without a Trash safety net:

# Step 1. Quit Cursor so no files are locked.
osascript -e 'quit app "Cursor"' 2>/dev/null
sleep 2

# Step 2. Audit the worst offenders. Note the workspace hashes.
du -sh ~/Library/Application\ Support/Cursor/User/workspaceStorage/*/ 2>/dev/null | sort -h | tail -10

# Step 3. Move the entire workspaceStorage subfolder to Trash for one workspace.
# Replace <hash> with a hash you no longer need.
mv ~/Library/Application\ Support/Cursor/User/workspaceStorage/<hash> \
   ~/.Trash/cursor-workspace-<hash>-$(date +%Y%m%d) 2>/dev/null

# Step 4. Or, less aggressive, only move .pack files for a workspace.
mv ~/Library/Application\ Support/Cursor/User/workspaceStorage/<hash>/*.pack \
   ~/.Trash/ 2>/dev/null
mv ~/Library/Application\ Support/Cursor/User/workspaceStorage/<hash>/*.idx \
   ~/.Trash/ 2>/dev/null

# Step 5. Reopen Cursor. It rebuilds workspace storage on next open.
open -a Cursor

Step 3 is the cleanest. Step 4 is for the workspace you still use and only want to drop heavy pack files for, which keeps state.vscdb intact. For a smaller incremental win, vacuum the SQLite database after pack cleanup:

sqlite3 ~/Library/Application\ Support/Cursor/User/workspaceStorage/<hash>/state.vscdb "VACUUM;" 2>/dev/null

That typically reclaims 10 to 100 MB per workspace.

How do you cap Cursor .pack files disk space so this does not happen again?

Cursor's recent update capped new workspaceStorage entries, but the cap does not retroactively shrink older packs or cap aggregation across workspaces. Two guardrails close the gap. Delete workspaceStorage subfolders for projects untouched for 60 days, Cursor rebuilds them on first reopen. Then schedule a monthly sweep with a Trash move for anything over a threshold you pick:

# Monthly sweep. Move any workspaceStorage subfolder over 2 GB to Trash.
find ~/Library/Application\ Support/Cursor/User/workspaceStorage \
  -mindepth 1 -maxdepth 1 -type d \
  -exec du -sm {} \; 2>/dev/null \
  | awk '$1 > 2048 { print $2 }' \
  | xargs -I {} mv {} ~/.Trash/ 2>/dev/null

Run that as a launchd job once a month and the path stops being a surprise. The reason to favor Trash over rm -rf is the one brtkwr's "Using Claude to free 200GB from a full disk" writeup makes explicit: "After the initial Docker/cache cleanup freed 150GB, going back and asking 'what else?' found another 75GB." The second pass only works because the first pass left a recovery path.

How does Cursor .pack files disk space compare to other AI editors?

This is a category pattern, not a Cursor-specific bug. Each AI-assisted editor has its own default-on, default-unbounded local history write.

Run two or more in parallel and expect cumulative bloat in the high tens to low hundreds of GB by month six. The fix is identical in every case: audit by size, move to Trash, never rm -rf blindly. Per-tool details are in How do I clean up Claude Code disk usage on my Mac? and Cursor cached data cleanup on Mac: the full sweep.

Why use CleanMyDev for Cursor .pack files instead of a shell script?

You do not need an app to run mv ... ~/.Trash/. You do need one the moment you have 90 workspace hashes, no idea which one corresponds to which project, and a deadline. CleanMyDev sizes every workspaceStorage subfolder, decodes the last-opened project path from state.vscdb, labels each .pack by age and size, and moves the candidates to Trash with one click. No rm -rf ever, restorable for 30 days.

It also knows the equivalent paths for Claude Code, Codex CLI, Cline, Windsurf, Ollama, and Hugging Face. CleanMyDev is $9.99 once, with the Cursor scanner preconfigured.

Related reading

• How do I clean up Claude Code disk usage on my Mac?
• Cursor cached data cleanup on Mac: the full sweep
• Codex CLI rollout sessions cleanup on Mac