Hey, this is a known issue. Cursor’s snapshot system currently doesn’t have a disk usage limit, so .pack files can build up without being cleaned up.
As a workaround, you can manually delete the contents of this folder:
~/Library/Application Support/Cursor/snapshots/
Cursor will recreate the needed files on the next launch. This is safe. You’ll only lose saved checkpoint states, not your code or settings.
The team is aware of the issue. Until there’s a fix, it makes sense to clean this folder from time to time if your disk starts filling up again.
Let me know if the problem comes back quickly after you delete it. That helps us prioritize it.
All I need to do is to activate cursor, and it will continuously write data to the file in /Library/Application\ Support/Cursor/snapshots/roots/sea-10449c74/objects/pack. It will take only a few minutes for the size to exceed 300G, completely filling up my hard drive space.
Steps to Reproduce
All I need is to simply open the cursor and use it normally. Even just opening the cursor is sufficient.
Version: 2.6.18, macOS arm64
Path: ~/Library/Application Support/Cursor/snapshots/roots/mediataal-cd8b6024/objects/pack/
Behavior: pack files of ~1GB are continuously created, even without an open project, and are immediately recreated after deletion
Steps to Reproduce
It happens immediately after opening the app. So even without opening a project. Also, even if I don’t have any extensions running.
It is reproducible every few hours, sometimes even when Cursor is not actively running or open, it continues to eat up disk space.
I’ve made an automation to delete /snapshot/ every 4 hours, it’d be great for this to be not neccessary.
With that in mind, it does stop me from opening other essential applications in turn I’d have to close Cursor and delete the snapshot before using other applications.
Windows here. Latest everything. My C:\Users\\AppData\Roaming\Cursor\User folder is over 32gigs!
And to add to my headaches, Cursor Network Diagnostics shows many network failures over the last few days.
The snapshots/roots/<project>/objects/pack/ directory accumulated 213 pack files
totaling 122 GB for a single project over approximately 3 days, with no automatic
cleanup occurring.
Environment
OS: macOS 15.4 (Darwin 25.4.0)
Cursor Version: (check your version in Cursor > About)
The pack directory silently accumulated 213 .pack files (each ~600–740 MB) plus
213 corresponding .idx files, totaling 122 GB — consuming the majority of the
available SSD storage. File distribution by date:
Mar 15: 69 pack files
Mar 17: 88 pack files
Mar 18: 56 pack files (still growing when discovered)
No automatic pruning, size limit, or warning was triggered.
Expected Behavior
Expected Behavior
The snapshot store should either:
Auto-prune old snapshots beyond a configurable retention count/size
Warn users when snapshot storage exceeds a threshold (e.g., 5 GB)
Expose a cleanup option in Settings UI
Workaround
Manually delete old pack files while keeping the most recent N:
cd "$HOME/Library/Application Support/Cursor/snapshots/roots/<project>/objects/pack"
KEEP=$(ls -t *.pack | head -5 | sed 's/\.pack$//')
for f in *.pack *.idx; do
BASE="${f%.*}"
if ! echo "$KEEP" | grep -qx "$BASE"; then rm "$f"; fi
done
### Operating System
MacOS
### Version Information
Version: 2.6.19 (Universal)
VSCode Version: 1.105.1
Commit: 224838f96445be37e3db643a163a817c15b36060
Date: 2026-03-12T04:07:27.435Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.4.0
### For AI issues: which model did you use?
sonnet-4.6
### Does this stop you from using Cursor
No - Cursor works, but with this issue
Hey everyone, I see that deleting the snapshots folder doesn’t help, the files get recreated almost instantly. That really does make the workaround useless, and I get the frustration.
A couple things:
Temporary workaround: @Chemchem pointed out that on version 2.5 the issue doesn’t reproduce. If this is critical, rolling back to 2.5 might help until a fix ships. Older versions are available at Cursor · Download.
I’ve told the team that the current workaround isn’t enough and the issue is more serious than it looked at first. Files are growing at gigabytes per second and get recreated right after deletion. There’s no fix timeline yet, but your reports with specific numbers like 122GB in 3 days, 300GB in minutes, growth at 1GB/sec help us prioritize.
@dirq, you’re on Windows and the folder C:\Users\<user>\AppData\Roaming\Cursor\User is 32GB. That could be the same issue but in a different path. Can you check if there’s a snapshots subfolder inside AppData\Roaming\Cursor\?
I’ll post an update here as soon as we have news on the fix.
This process begins writing large amounts of data to disk continuously.
Observed Behavior
• Occurs simply by opening Cursor
• No agent interaction required
• Disk writes escalate rapidly (30GB+ within minutes)
• Activity Monitor shows sustained high write rates
• System becomes noticeably sluggish
Steps to Reproduce
1. Open Cursor
2. Do nothing
3. Observe Activity Monitor → Disk tab
4. “Cursor Helper (Plugin) – retrieval-always-local” begins writing continuously
Expected Behavior
Impact
• Disk usage increased from ~786 GB to ~957 GB during testing
• Risk of completely filling disk
• Significant system slowdown
• Requires manual force quit to stop
Reproducibility
• Happens consistently on my machine
• Occurs simply by opening Cursor and waiting
• No agent interaction required
Version Comparison
• This issue does NOT occur on another Mac running an older version of Cursor
• Suggests a regression introduced in a recent update
The snapshot .pack file disk space issue has been addressed in a recent Cursor update. A disk usage limit for snapshot pack files has been implemented. Updating to the latest version should resolve this.
