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

**URL:** <https://forum.cursor.com/t/gc-agent-kv-blobs-temporarily-consumed-62-gb-of-free-space-while-compacting-a-29-gb-state-vscdb/172165>\
**Category:** Help\
**Tags:** performance\
**Created:** [September 18, 2026, 3:51pm UTC](https://forum.cursor.com/t/gc-agent-kv-blobs-temporarily-consumed-62-gb-of-free-space-while-compacting-a-29-gb-state-vscdb/172165 "2026-09-18T15:51:05Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ionut\_Rata](https://avatars.discourse-cdn.com/v4/letter/i/45deac/32.png) [@Ionut\_Rata](https://forum.cursor.com/u/Ionut_Rata)\
**Post date:** [September 18, 2026, 3:51pm UTC](https://forum.cursor.com/t/gc-agent-kv-blobs-temporarily-consumed-62-gb-of-free-space-while-compacting-a-29-gb-state-vscdb/172165/1 "2026-09-18T15:51:06Z")

</div>

$ 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?

---

<div class="post-metadata">

**Author:** ![MemorySync](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/memorysync/32/121144_2.png) [@MemorySync](https://forum.cursor.com/u/MemorySync)\
**Post date:** [September 18, 2026, 4:54pm UTC](https://forum.cursor.com/t/gc-agent-kv-blobs-temporarily-consumed-62-gb-of-free-space-while-compacting-a-29-gb-state-vscdb/172165/5 "2026-09-18T16:54:38Z")

</div>

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.
