Useful info, thanks. The fact that VACUUM didn’t shrink the file is expected. This isn’t fragmentation, it’s real data. The cursorDiskKV table keeps accumulating chat, checkpoint, and agent data with no cleanup mechanism. Other users are seeing the same thing.
Instead of VACUUM, you need to delete specific key families. Fully close Cursor, then run:
sqlite3 ~/.config/Cursor/User/globalStorage/state.vscdb <<'SQL'
PRAGMA journal_mode=DELETE;
BEGIN IMMEDIATE;
DELETE FROM cursorDiskKV WHERE key LIKE 'agentKv:%';
DELETE FROM cursorDiskKV WHERE key LIKE 'bubbleId:%';
DELETE FROM cursorDiskKV WHERE key LIKE 'checkpointId:%';
COMMIT;
VACUUM;
SQL
This will clear the main space hogs. For another user, the DB dropped from about 13,7 GB to 23 MB after this. Side effect is that existing chats may show “Loading Chat…” Full transcripts are saved in ~/.cursor/projects/*/agent-transcripts/*.jsonl. Just in case, back up state.vscdb before running it.
More details, including a full script with backup: Cursor state.vscdb growing at 1 GB in a day - #7 by rifont
About the dbstat error after VACUUM, it might be due to the version of the sqlite3 CLI on your system. Not a big deal, the important part is running the cleanup above.
Also, about the crashes after about an hour, they might continue even after the DB cleanup. Another user with a similar setup found the crashes were caused by a runtime issue, a memory spike in retrieval indexing, not the DB size. As a workaround, you can roll back to version 2.5.26, which seems more stable for this.