Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Cursor’s local SQLite database (state.vscdb) grows continuously over time until it reaches tens of gigabytes, eventually filling the disk and making Cursor difficult or impossible to use.
After investigating the database, I found that almost all of the growth comes from millions of Agent/Composer-related records (bubbleId, agentKv, checkpointId) stored in cursorDiskKV.
Deleting Composer chats from the UI does not reduce the database size.
Steps to Reproduce
- Use Cursor Agent / Composer extensively over several weeks.
- Create and delete many Agent conversations.
- Continue normal development work.
- Observe that:
- state.vscdb continues growing.
- Deleted conversations do not reduce its size.
- Eventually the database reaches tens of GB.
Expected Behavior
Deleting Composer/Agent conversations should eventually release the associated local storage.
state.vscdb should not continuously grow without cleanup, and old Agent/Composer data should be garbage-collected automatically.
The database size should remain reasonable instead of growing to tens of gigabytes.
Screenshots / Screen Recordings
Operating System
MacOS
Version Information
Version 3.14.7
For AI issues: which model did you use?
Composer 2.5 , Claude Opus 4.8
Additional Information
Investigation results:
state.vscdb size:
~30 GB
SQLite tables:
- ItemTable: 477 rows
- cursorDiskKV: 1,962,076 rows
- composerHeaders: 397 rows
cursorDiskKV distribution:
- bubbleId: 1,325,748 rows
- agentKv: 582,384 rows
- checkpointId: 4,128 rows
- composerData: 428 rows
I currently have only about 5-6 active Agent conversations, and I already deleted most old conversations from the UI.
The database size did not decrease.
I intentionally have not deleted state.vscdb because I want to preserve project context if possible.
Please let me know whether this is a known issue and whether there is an officially supported way to safely clean or rebuild this database.
Does this stop you from using Cursor
Yes - Cursor is unusable
Hey!
To actually reclaim the space, open the Command Palette (Cmd+Shift+P) and run:
Developer: GC Agent KV Blobs - cleans up orphaned agent data and compacts the database. It does not delete your chats. On a 30 GB DB it can take a while, so let the dialog finish. This is usually the missing step after UI deletions.- Optional —
Developer: Delete Old Chats… - deletes chats older than a cutoff you pick, then compacts. This permanently removes that history, so only use it if you’re okay losing it.
One honest caveat: a lot of your 30 GB is agent history no longer tied to a visible chat, and that portion doesn’t always get reclaimed yet, so the file may not drop all the way. That gap is part of what we’re tracking.
Don’t delete state.vscdb itself (you were right to keep it - removing it can leave projects stuck on “Loading Chat…”). If there’s a large state.vscdb.backup next to it, that one is safe to move aside for a quick separate win.
If it doesn’t reclaim much, reply with the before/after size and I’ll take another look.
I have an update after running GC Agent KV Blobs.
The command completed the scanning phase:
- Composer data (449 items)
- Bubbles (1,332,518 items)
It then proceeded to:
GC Agent KV Blobs: Compacting Storage
However, during the compaction phase, Cursor failed with Disk Full.
I first tried with about 2 GB of free disk space, then freed approximately 11 GB and tried again. The exact same thing happened: it reached “Compacting Storage” and then failed because the disk became full.
After the failed operation:
state.vscdb is still 30 GB- No disk space was reclaimed
I also inspected the SQLite database:
cursorDiskKV: 1,962,076 rowsbubbleId:*: ~1.33M entriesagentKv:*: ~582k entries
A few questions:
- Approximately how much free disk space is required to successfully compact a 30 GB
state.vscdb?
- Is the compaction creating a second copy of the database, which is why it runs out of space?
- Is there a lower-disk-space method to reclaim this storage?
- Does Developer: Delete Old Chats also remove the associated
agentKv, bubbleId, and checkpointId entries from cursorDiskKV, or does it only remove the visible chat history?
At the moment I’m stuck because I need to reclaim disk space, but I can’t compact the database since the database itself is consuming the space required for the compaction.
Thanks!
complete nonsense.. i was having 45gb free hdd; and tried “GC Agent KV Blobs”… and again, i got “not enough space” error after compacting storage process.
the app was already taking up a ridiculous 30GB of my space, and cleaning it up used another 45GB, and it still wasn’t enough.
Sorry, that’s a fair reaction. Short version: the compaction genuinely can’t help you here, so the way to get unblocked now is to move the oversized database aside and let Cursor rebuild a fresh one:
- Fully quit Cursor (
Cmd+Q).
- In Finder, open
~/Library/Application Support/Cursor/User/globalStorage/.
- Move (don’t delete)
state.vscdb - and state.vscdb.backup if it’s there - to an external drive or another folder. Moving keeps a full copy, so nothing’s lost and you can pull context back later.
- Reopen Cursor - it rebuilds a small database and your ~30 GB is freed right away.
This resets your local chat history on this machine (code and projects are untouched); keep the moved file as your backup rather than deleting it. It’s the trade-off I mentioned earlier, but since compaction won’t complete on your free space, reclaiming the disk comes first.
On your questions: yes, the compaction writes a full second copy of the database before swapping, so it needs roughly the DB size again, up to ~2×, so ~45–60 GB for a 30 GB file. Almost none of your 30 GB is reclaimable (it’s agent history no longer tied to a visible chat, which is the part we’re still working on), so that copy comes out near full-size and never fits. And Delete Old Chats does delete the underlying records for chats it removes, but it won’t reach already-orphaned history and won’t shrink the file on an older database - so it wouldn’t help much here either.
