Cursor state.vscdb growing at 1 GB in a day

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

I’ve used Cursor for 2 months.
3 weeks ago, (about 20 Jan) state.vscdb was 5 GB
Yesterday morning (13 Feb, 10.00 am) state.vscdb was 7.27 GB
Yesterday evening (13 Feb, 10.00 am) state.vscdb was 8.20 GB
Growth of 1 GB in 12 hrs.
Is this something like a DOS attack or worse?

Steps to Reproduce

I don’t know

Expected Behavior

vscdb shouldnt grow at this rate. Soon I will be out of hard drive space and wont be able to use cursor.

Operating System

Windows 10/11

Version Information

Sorry wont get that. I’ve just updated to the latest before this.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the report. 8 GB for state.vscdb is definitely not normal.

A few things that’ll help narrow this down:

  1. Which state.vscdb file is growing? The global one at %APPDATA%\Cursor\User\globalStorage\state.vscdb, or the one inside a specific workspace at %APPDATA%\Cursor\User\workspaceStorage\<id>\state.vscdb?
  2. Your exact Cursor version. Open Help > About and you’ll see it there.
  3. About how many workspaces or projects do you usually have open?

As a temporary workaround to free up space right now: fully close Cursor, then open the enlarged state.vscdb in any SQLite tool, like DB Browser for SQLite, and run:

VACUUM;

This will compact the database and reclaim unused space. You can also check which tables take up the most space, which will help us understand what’s causing the growth.

No need to worry about a DOS attack, it’s just an internal database that grew larger than it should. The team is aware of size issues and it’s on our radar. Send the details above and let me know how the VACUUM went.

Hi
I tried running “VACUUM;” on the state.vscdb and file size and table seemed to be exact the same size before and after. So this does not seem to be a solution. I am on 24gb now and my computer is starting to complain about disk space. So more potential solutions are welcome.

@deanrie - Forgot to mention you for the message above.

Hey, @Teglgaard 24 GB is way out of proportion. If VACUUM didn’t shrink the file, it means it’s actually full of data, not just fragmented.

To figure out what’s taking up all that space, please do this:

SELECT name, SUM(pgsize) as size_bytes 
FROM dbstat 
GROUP BY name 
ORDER BY size_bytes DESC 
LIMIT 10;

Also important, which state.vscdb is it exactly. The global one at %APPDATA%\Cursor\User\globalStorage\state.vscdb, or the one inside workspaceStorage\<some-id>\state.vscdb?

If you need free disk space right now, close Cursor, rename the file to state.vscdb.bak, and restart. Cursor will create a new file. Warning: if this is the global state.vscdb, renaming it can cause an infinite “Loading Chat…” in existing projects (known issue: Deleting global state.vscdb causes infinite 'Loading Chat' in projects, history not recoverable without corrupted backup). Your chats won’t be deleted (they’re in workspaceStorage), but they’ll be inaccessible until you restore the original file. Keep a backup.

Let me know what the request returns.

I also encountered high state.vscdb size at ~13.7GB. I havent’t definitively diagnosed cause, but I did recently start adding many cloned Git repos into my project filesystem under /repos/* weighing in at around 77GB (note, these were just git cloned, not git submodules). I didn’t have a .cursorignore for those initially and Cursor may have started indexing or doing something with those files? The symptoms leading me here was Cursor staying alive for around 10-15 minutes before crashing with error below. The crash often accompanied a CPU activity spike, but not always.

My attempt to cleanup follows, I’m monitoring for addition crashes presently (cleanup script collapsed below). This got the state.vscdb down to 23.8MB.

—-

I ran this on the global DB:
~/Library/Application Support/Cursor/User/globalStorage/state.vscdb

SELECT name, SUM(pgsize) AS size_bytes
FROM dbstatGROUP 
BY nameORDER 
BY size_bytes 
DESCLIMIT 10;

Result:

  • cursorDiskKV: 13,641,699,328 bytes
  • sqlite_autoindex_cursorDiskKV_1: 99,713,024 bytes
  • ItemTable: 5,296,128 bytes
  • sqlite_autoindex_ItemTable_1: 225,280 bytes

Counts:

  • cursorDiskKV rows: 976,000
  • ItemTable rows: 2,338

Integrity check:
PRAGMA integrity_check;
=> fails with “database disk image is malformed” and index errors (sqlite_autoindex_cursorDiskKV_1).

Sampling cursorDiskKV keys (first 20k rows) shows biggest prefixes are:
bubbleId, agentKv, checkpointId, messageRequestContext, codeBlockDiff.

So in my case the bloat is real payload growth in cursorDiskKV (not just fragmentation), and the backup DB also shows corruption signals.

I ran this script below to test if DB shrinking fixes, NOTE, this backs up the existing state.vscdb store, but “Loading Chat” will occur in all chats and has a known bug as above. Though full jsonl chat transcripts are available at ~/.cursor/projects//agent-transcripts//.jsonl and not lost.

Cleanup script
# Cursor state.vscdb cleanup + compaction (macOS)
# This removes the large cursorDiskKV payload families and shrinks the DB file.

set -euo pipefail

DB="$HOME/Library/Application Support/Cursor/User/globalStorage/state.vscdb"
DIR="$HOME/Library/Application Support/Cursor/User/globalStorage"
TS="$(date +%Y%m%dT%H%M%S)"

echo "Using DB: $DB"

# 1) Stop Cursor first (important to avoid lock/partial writes)
pkill -f '/Applications/Cursor.app/Contents/MacOS/Cursor' || true
pkill -f '/Applications/Cursor.app/Contents/Frameworks/Cursor Helper' || true
sleep 1

# 2) Backup
cp "$DB" "$DIR/state.vscdb.bak-precleanup-$TS"
echo "Backup created: $DIR/state.vscdb.bak-precleanup-$TS"

# 3) Delete biggest offenders (chat/composer/checkpoint blob families) + compact
sqlite3 "$DB" <<'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;
PRAGMA wal_checkpoint(TRUNCATE);
SQL

# 4) Verify
echo
echo "Post-cleanup counts:"
sqlite3 "$DB" "
SELECT 'agentKv', COUNT(*) FROM cursorDiskKV WHERE key LIKE 'agentKv:%'
UNION ALL
SELECT 'bubbleId', COUNT(*) FROM cursorDiskKV WHERE key LIKE 'bubbleId:%'
UNION ALL
SELECT 'checkpointId', COUNT(*) FROM cursorDiskKV WHERE key LIKE 'checkpointId:%';
"

echo
echo "File sizes:"
ls -lh "$DB" "$DIR"/state.vscdb.bak-precleanup-"$TS"
stat -f '%N %z bytes' "$DB" "$DIR"/state.vscdb.bak-precleanup-"$TS"

There are related issues being reported in the last 24 hours. Seems like it could be a bug in Cursor sqlite usage for this store.

https://www.reddit.com/r/cursor/comments/1rkyfu9/super_crashy_recently/
https://x.com/yannschaub/status/2029387568056537266

The crashing behavior persists, I used Codex to profile memory and record high-res logs whilst Cursor went through 10-15 minute crash cycles, here are the findings.

Hopefully you can fix it soon, Cursor is unusable for me right now for any non-trivial agentic work, given it crashes within 15 minutes.

The Codex transcript is below, I have also attached the log files which record the failure scenario playing out. Let me know if I can provide any other supporting files!


Codex - GPT 5.3 Extra High analysis

cursor-crash-forum-logs-20260306.zip (137.2 KB)

I collected high-resolution logs/metrics and found a consistent crash signature that points to Cursor retrieval indexing (not DB size) as the immediate cause.

Environment

  • Version: 2.6.11
    VSCode Version: 1.105.1
    Commit: 8c95649f251a168cc4bb34c89531fae7db4bd990
    Date: 2026-03-03T18:57:48.001Z
    Build Type: Stable
    Release Track: Default
    Electron: 39.6.0
    Chromium: 142.0.7444.265
    Node.js: 22.22.0
    V8: 14.2.231.22-electron.0
    OS: Darwin arm64 25.0.0
  • Date of measured crashes: 2026-03-05
  • global state DB was already reduced; at crash time metrics show state_db_mb=22.7 (so this is not a “24 GB DB” event anymore)

Crash signature (repeats)

  • Renderer crash: “CodeWindow: renderer process gone (reason: crashed, code: 5)”
  • Example crashes:
    • /Users/rifont/Library/Application Support/Cursor/logs/20260305T231731/main.log:8 (23:27:36.836)
    • /Users/rifont/Library/Application Support/Cursor/logs/20260305T231731/main.log:16 (23:52:41.187)

Pre-crash process surge (from vitals monitor CSV)

  • /Users/rifont/Library/Application Support/Cursor/vitals-monitor/metrics.csv
  • Crash @ 23:27:36:
    • retrieval-always-local host (pid 63435): 393.8 MB @ 23:27:31 → 1451.2 MB @ 23:27:36, CPU ~142% just before jump
      • lines: 4007, 4021
    • renderer (pid 62909): 878.9 MB @ 23:27:31 → 1748.4 MB @ 23:27:36
      • lines: 4005, 4019
  • Crash @ 23:52:41:
    • retrieval-always-local host (pid 84051): 307.9 MB → 1493.2 MB with CPU 127.5%
      • line: 6172 (23:52:38)
    • then renderer crashes ~3s later (main.log line 16)

Needle in haystack (likely trigger patterns)

  1. Huge watcher/event expansion in retrieval grep service
  • /Users/rifont/Library/Application Support/Cursor/logs/20260305T162948/window8/exthost/anysphere.cursor-retrieval/Cursor Grep Service.log
  • “expanded 1 directories into 1007872 file events” (line 29)
  • then “found 9637 pending documents; triggering a reset” (line 34)
  • then “FORCE resetting index” (line 36)
  1. Path-normalization/hash retry storm in retrieval indexing
  • /Users/rifont/Library/Application Support/Cursor/logs/20260305T162948/window9/exthost/anysphere.cursor-retrieval/Cursor Indexing & Retrieval.log
  • hundreds of repeated:
    • fatal: could not open ‘/Users/rifont/git/tau/vscode/settings.json’
    • command repeatedly runs git hash-object ... /vscode/settings.json ... (missing leading dot)
  • starts around line 33 and continues through line 216
  • similar malformed-path misses also seen for oxlintrc.json / github/workflows/ci.yml in other windows (missing leading dot variants)
  1. HEAD-change correlation right before crash
  • /Users/rifont/Library/Application Support/Cursor/logs/20260305T231731/window1/exthost/anysphere.cursor-retrieval/Cursor Grep Service.log
    • 23:27:34.986 “git head changed …”
    • crash at 23:27:36.836 (~2s later)

Why I think this is the bug

  • The largest immediate RSS spike is consistently in retrieval-always-local extension host.
  • Renderer memory then spikes and dies with code 5.
  • This still happens after state.vscdb was shrunk, so current crash is runtime indexing/watcher pressure, not DB file bloat.

Useful fix directions

  • Instrument/limit retrieval host memory + pending event queue.
  • Add hard backpressure/guardrails when watcher expansion is huge.
  • Fix path normalization (.vscode/settings.json vs vscode/settings.json, same for .oxlintrc.json, .github/...).
  • Prevent retry storms for repeatedly missing files.
  • Consider excluding .git/* internals from retrieval sync/hash churn.

The only way I could resolve the issue was by rolling back to Version: 2.5.26 - Cursor · Download. I’m not experiencing any crashes now after several hours of use.

Issue appears resolved in version 2.6.18

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

state.vscdb in globalStorage grows to 1.7 GB over normal usage due to two issues:

1. cursorDiskKV table grows unbounded — 225K rows, 1.53 GB of chat/agent data with no expiration or cleanup:

  • bubbleId (chat bubbles): 107K rows, 824 MB
  • agentKv (agent blobs): 107K rows, 578 MB
  • checkpointId (snapshots): 3.4K rows, 85 MB
  • Single entries up to 13 MB, average 7 KB

2. SQLite nested transaction bug in AgentAnalyticsOperationsMainService:

SQLITE_ERROR: cannot start a transaction within a transaction

This error fires repeatedly in main.log for both storing pre-generated AI code hashes and marking commits as scored.

Impact: After 3 days continuous use, total Cursor RSS hit ~12 GB. Close operation took 3.28s (detected slow close() operation: Time: 3283ms, DB size: 1827930112b). The DB + backup + WAL can consume 3-5 GB disk.

Steps to Reproduce

  1. Use Cursor normally for a few weeks (have multiple chat/agent conversations)
  2. Check database size:
ls -lh ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb
  1. Inspect cursorDiskKV:
sqlite3 ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb \
  "SELECT count(*), sum(length(value))/1024/1024 || ' MB' FROM cursorDiskKV;"
  1. Check nested transaction errors:
grep "cannot start a transaction" ~/Library/Application\ Support/Cursor/logs/*/main.log

Expected Behavior

  1. Old conversation data in cursorDiskKV should have a retention policy (TTL, size cap, or archival) instead of accumulating indefinitely.
  2. AgentAnalyticsOperationsMainService should not start nested transactions — each transaction should be properly committed/rolled back before starting a new one.
  3. The database should stay at a reasonable size (tens of MB, not GB) for an editor’s state storage.

Operating System

MacOS

Version Information

Operating System

macOS (darwin 25.3.0)

Cursor Version

2.6.19

Does this stop you from using Cursor

No - Cursor works, but with this issue

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor is taking almost 30 GB on my disk, and it seems most of the space is used by the state.db and state.db backup.
This seems not normal. Is it safe to delete it?
I’ve seen another issue (Deleting global state.vscdb causes infinite 'Loading Chat' in projects, history not recoverable without corrupted backup) that deleting it could cause a broken state in the chat indexing.
I already tried to run the vacuum command on the SQLite database as suggested, but without any success.

Steps to Reproduce

Use cursor

Expected Behavior

Should not take so much space or at least should be safe to delete

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 2.5.26
VSCode Version: 1.105.1
Commit: 7d96c2a03bb088ad367615e9da1a3fe20fbbc6a0
Date: 2026-02-26T04:57:56.825Z
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.3.0

For AI issues: which model did you use?

Opus 4.6

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the report. I see the screenshot. 12,7 GB for state.vscdb plus 12,4 GB for the backup is definitely not normal.

This is a known issue. A few users are reporting the same uncontrolled growth. As you already saw, VACUUM doesn’t help in these cases, so it’s not fragmentation. It’s actual accumulated data.

I wouldn’t delete state.vscdb. Like you found, it breaks chat loading: Deleting global state.vscdb causes infinite 'Loading Chat' in projects, history not recoverable without corrupted backup

If you want to help us debug, you can check which tables are bloated. Fully quit Cursor, then run:

sqlite3 ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb "SELECT name, SUM(pgsize) as size FROM dbstat GROUP BY name ORDER BY size DESC LIMIT 10;"

This will show the top 10 tables by size. Seeing that output would be really helpful.

I’ve shared this with the team along with other similar reports. For now, unfortunately, there isn’t a reliable workaround. Let me know what you get from the request above.

Sure, here is the query result

❯ sqlite3 ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb "SELECT name, SUM(pgsize) as size FROM dbstat GROUP BY name ORDER BY size DESC LIMIT 10;"
cursorDiskKV|12657577984
sqlite_autoindex_cursorDiskKV_1|110379008
ItemTable|6103040
sqlite_autoindex_ItemTable_1|450560
sqlite_schema|4096

I also asked claude to run some analysis maybe it helps

“““

Database Size Summary

Total database size: ~12.6 GB (cursorDiskKV table dominates at 12.6 GB)

Key Findings:

cursorDiskKV Table (1,079,250 rows, ~11 GB of data)

  • Almost all rows have unique keys (1,079,056 unique keys)
  • Only 194 rows have empty/null keys (357 MB)
  • Storage breakdown by data type:
    • agentKv (556K rows): 5.9 GB - This is the main culprit
    • bubbleId (403K rows): 3.4 GB
    • checkpointId (48K rows): 933 MB
    • composerData (4.5K rows): 322 MB
    • codeBlockDiff (30K rows): 207 MB
    • Others (messageRequestContext, inlineDiff, etc.): ~133 MB combined

ItemTable (4,477 rows, ~6 MB total)

  • Mostly empty/unnamed keys (~4,467 entries, 5.3 MB)
  • Small amounts of metadata (secret, windowInWindowReload, etc.)

Top Space Consumers:

  • Individual agentKv:blob entries range from 3-15 MB each
  • Top single entry: agentKv:blob:8d5601fa8abb812e… at 14.9 MB
  • Some bubbleId entries also reach 13+ MB
  • Several checkpointId entries are 17-23 MB each

Likely Causes:

  1. Agent-related data accumulation - The agentKv:blob keys make up half the database and likely contain conversation history, snapshots, or AI-generated content that’s never cleaned up
  2. Conversation bubbles - bubbleId entries (probably chat/code bubbles) are also quite large and numerous
  3. Checkpoints - Version/undo history snapshots are taking up significant space
  4. No cleanup mechanism - The database just keeps growing with 1M+ entries”””

“““