# Cursor state.vscdb growing at 1 GB in a day

**URL:** <https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747>\
**Category:** Bug Reports\
**Tags:** performance\
**Created:** [February 13, 2026, 6:11am UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747 "2026-02-13T06:11:45Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![skmuchiri](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/skmuchiri/32/98153_2.png) [@skmuchiri](https://forum.cursor.com/u/skmuchiri)\
**Post date:** [February 13, 2026, 6:11am UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747/1 "2026-02-13T06:11:45Z")

</div>

### 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

---

<div class="post-metadata">

**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\
**Post date:** [February 13, 2026, 7:23am UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747/3 "2026-02-13T07:23:21Z")

</div>

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](https://sqlitebrowser.org/), and run:

```sql
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.

---

<div class="post-metadata">

**Author:** ![Teglgaard](https://avatars.discourse-cdn.com/v4/letter/t/b5ac83/32.png) [@Teglgaard](https://forum.cursor.com/u/Teglgaard)\
**Post date:** [February 26, 2026, 3:50pm UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747/4 "2026-02-26T15:50:11Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Teglgaard](https://avatars.discourse-cdn.com/v4/letter/t/b5ac83/32.png) [@Teglgaard](https://forum.cursor.com/u/Teglgaard)\
**Post date:** [March 5, 2026, 9:00am UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747/5 "2026-03-05T09:00:31Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\
**Post date:** [March 5, 2026, 9:20am UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747/6 "2026-03-05T09:20:28Z")

</div>

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:

- Fully close Cursor.
- Open `state.vscdb` in [DB Browser for SQLite](https://sqlitebrowser.org/).
- Run this and share the results:

```sql
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](https://forum.cursor.com/t/deleting-global-state-vscdb-causes-infinite-loading-chat-in-projects-history-not-recoverable-without-corrupted-backup/153220)). 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.

---

<div class="post-metadata">

**Author:** ![rifont](https://avatars.discourse-cdn.com/v4/letter/r/65b543/32.png) [@rifont](https://forum.cursor.com/u/rifont)\
**Post date:** [March 5, 2026, 10:04am UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747/7 "2026-03-05T10:04:23Z")

</div>

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.

 ![image](https://us1.discourse-cdn.com/cursor1/original/3X/3/6/36ac1e2335370dc449b19adab66efec5129b2225.jpeg)

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

```sql
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**
>
> ```python
> # 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"
> 
> ```

---

<div class="post-metadata">

**Author:** ![rifont](https://avatars.discourse-cdn.com/v4/letter/r/65b543/32.png) [@rifont](https://forum.cursor.com/u/rifont)\
**Post date:** [March 5, 2026, 10:12am UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747/9 "2026-03-05T10:12:11Z")

</div>

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.

> [@Cursor IDE crash during agent work](https://forum.cursor.com/t/cursor-ide-crash-during-agent-work/153268/3):
>
> Hey, thanks for the detailed report. It’s especially helpful that you tracked it down to state.vscdb as the cause. There are actually two issues here: state.vscdb grows to a huge size 11,4 GB plus a 10,7 GB backup is definitely not normal. Other users are seeing the same thing: [Cursor state.vscdb growing at 1 GB in a day](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747). As a temporary workaround: Fully quit Cursor Delete state.vscdb.backup (it’s just a backup, safe to remove) Open state.vscdb in DB Browser for SQLite: [https://sqlitebrows…](https://sqlitebrowser.org/)

> [@Cursor state.vscdb 25gb+](https://forum.cursor.com/t/cursor-state-vscdb-25gb/153661):
>
> 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](https://forum.cursor.com/t/deleting-global-state-vscdb-causes-infinite-loading-chat-in-projects-history-not-recoverable-without-corrupted-backup/153220)) that deleting it could cause a broken state in the chat indexing. I already tried to run the vacuum command on…

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

---

<div class="post-metadata">

**Author:** ![rifont](https://avatars.discourse-cdn.com/v4/letter/r/65b543/32.png) [@rifont](https://forum.cursor.com/u/rifont)\
**Post date:** [March 5, 2026, 11:19am UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747/10 "2026-03-05T11:19:13Z")

</div>

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](https://forum.cursor.com/uploads/short-url/9Vw0HeFNNTUBtnoEuj94rAe1U4G.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.

---

<div class="post-metadata">

**Author:** ![rifont](https://avatars.discourse-cdn.com/v4/letter/r/65b543/32.png) [@rifont](https://forum.cursor.com/u/rifont)\
**Post date:** [March 6, 2026, 12:53am UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747/11 "2026-03-06T00:53:54Z")

</div>

The only way I could resolve the issue was by rolling back to `Version: 2.5.26` - [Cursor · Download](https://cursor.com/download). I’m not experiencing any crashes now after several hours of use.

---

<div class="post-metadata">

**Author:** ![rifont](https://avatars.discourse-cdn.com/v4/letter/r/65b543/32.png) [@rifont](https://forum.cursor.com/u/rifont)\
**Post date:** [March 12, 2026, 7:38pm UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747/12 "2026-03-12T19:38:21Z")

</div>

Issue appears resolved in version `2.6.18`

---

<div class="post-metadata">

**Author:** ![dovecheng](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/dovecheng/32/102214_2.png) [@dovecheng](https://forum.cursor.com/u/dovecheng)\
**Post date:** [March 18, 2026, 3:13pm UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747/13 "2026-03-18T15:13:33Z")

</div>

### 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:**

```auto
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:

```bash
ls -lh ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb

```

1. Inspect cursorDiskKV:

```bash
sqlite3 ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb \
  "SELECT count(*), sum(length(value))/1024/1024 || ' MB' FROM cursorDiskKV;"

```

1. Check nested transaction errors:

```bash
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

---

<div class="post-metadata">

**Author:** ![tonxxd](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/tonxxd/32/90003_2.png) [@tonxxd](https://forum.cursor.com/u/tonxxd)\
**Post date:** [March 5, 2026, 7:27am UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747/15 "2026-03-05T07:27:10Z")

</div>

### 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](https://forum.cursor.com/t/deleting-global-state-vscdb-causes-infinite-loading-chat-in-projects-history-not-recoverable-without-corrupted-backup/153220)) 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

 ![Screenshot 2026-03-05 alle 08.21.54.png](https://us1.discourse-cdn.com/cursor1/original/3X/b/b/bb569ca322f96f773c9b2bc49c8b1e46d765fe0c.jpeg)

### 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

---

<div class="post-metadata">

**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\
**Post date:** [March 5, 2026, 8:55am UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747/17 "2026-03-05T08:55:18Z")

</div>

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](https://forum.cursor.com/t/deleting-global-state-vscdb-causes-infinite-loading-chat-in-projects-history-not-recoverable-without-corrupted-backup/153220)

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

```sql
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.

---

<div class="post-metadata">

**Author:** ![tonxxd](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/tonxxd/32/90003_2.png) [@tonxxd](https://forum.cursor.com/u/tonxxd)\
**Post date:** [March 5, 2026, 1:39pm UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747/18 "2026-03-05T13:39:52Z")

</div>

Sure, here is the query result

```bash
❯ 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”””

“““

---

<div class="post-metadata">

**Author:** ![system](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/system/32/99069_2.png) [@system](https://forum.cursor.com/u/system)\
**Post date:** [April 9, 2026, 4:38pm UTC](https://forum.cursor.com/t/cursor-state-vscdb-growing-at-1-gb-in-a-day/151747/21 "2026-04-09T16:38:18Z")

</div>

Closed on April 9, 2026, 4:38pm UTC

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.