“GC Agent KV Blobs” temporarily consumed ~62 GB of free space while compacting a 29 GB state.vscdb

Support Help
1

$ du -sh ~/.config/Cursor/User/globalStorage
31G /home/rata-ionut/.config/Cursor/User/globalStorage

$ ls -lh ~/.config/Cursor/User/globalStorage/state.vscdb*
-rw------- 1 user user 29G state.vscdb
-rw------- 1 user user 96K state.vscdb-shm
-rw------- 1 user user 0 state.vscdb-wal

Free space before GC: ~66 GB
Lowest free space during: ~4 GB
Temporary space consumed: ~62 GB

Persistent state.vscdb: ~29 GB

This means the GC operation temporarily required roughly twice the size of the database in additional free space, with the total disk footprint associated with the database/compaction reaching close to 90 GB.
Is this amount of temporary disk usage expected for GC Agent KV Blobs?
Does the GC perform a SQLite VACUUM or create multiple temporary copies of state.vscdb?
Is there a recommended minimum amount of free disk space relative to the size of state.vscdb before running this command?
Is a 29 GB state.vscdb considered normal for heavy Agent usage, or does this indicate excessive accumulation of Agent KV blobs or other cached data?
Can Cursor compact or clean this database in a more space-efficient way, especially on systems with limited disk space?

5

Yes, this ~2x temporary disk usage is expected behavior for SQLite when performing an un-chunked full VACUUM.

Here is what is happening under the hood and how to manage it:

  1. Why 62 GB was consumed:
    Cursor’s state.vscdb is a standard SQLite database running in WAL mode. When GC Agent KV Blobs completes deleting rows, it triggers a SQLite VACUUM to reclaim empty pages and defragment B-trees. Standard SQLite VACUUM works by creating a completely new, separate database file on disk, copying all surviving pages into it, and keeping the old database + journal/WAL files intact until the final atomic rename. For a 29 GB file, the temporary target database (~29 GB) plus temporary journal pages easily demands 60–65 GB of free headroom.

  2. Is 29 GB normal for state.vscdb?
    No, 29 GB is excessively bloated. This happens during heavy Composer / Agent usage when full multi-turn chat transcripts, raw tool stdout dumps, and large git diff blobs get serialized into the local VS Code globalStorage KV table without prompt eviction.

  3. How to prevent disk exhaustion on smaller drives:

  • Temporary directory redirect: You can instruct SQLite to write temporary compaction files to a secondary drive with more space by setting the environment variable SQLITE_TMPDIR=/path/to/larger/disk before launching Cursor.
  • Incremental vacuum: Rather than a monolithic full VACUUM, SQLite supports PRAGMA auto_vacuum = INCREMENTAL; followed by scheduled PRAGMA incremental_vacuum(N); to reclaim pages in smaller, bounded chunks without doubling the whole file footprint.
  • State hygiene: Avoid storing multi-megabyte tool execution logs and history blobs locally in globalStorage; externalizing durable agent state to an isolated key-value / MCP store keeps state.vscdb consistently under 500 MB.