State.vscdb grew from 3.1 GB → 97 GB (macOS)

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I checked the storage usage of my Mac and Cursor is using quite a lot of storage. I used Grok 4.5 to investigate the issue and it came back with the following result. It would be nice if you could tell me a) how to investigate this further or b) what steps I could take. I dont want to “just delete” either the whole or parts of the state.vscdb file.

Here is the resulting analysis:

The global state.vscdb on this machine has grown to an extreme size and is dominating local disk use for Cursor.

File Size Notes
state.vscdb (live) 97.09 GB Measured 2026-07-17
state.vscdb.backup 3.06 GB Last written 2026-05-12 — best historical size anchor
Implied growth +94.0 GB in ~66 days ≈ 1.42 GB/day if treated as roughly continuous

This matches the known unbounded cursorDiskKV growth reports, but at a more extreme scale than the common 1–20 GB cases.

I have not deleted or renamed the live DB (aware that doing so can cause endless “Loading Chat…”).

What’s inside the 97 GB (read-only SQLite)

Tables:
  ItemTable          ~1.7k rows
  composerHeaders    ~2,546 rows (1,163 marked subagent)
  cursorDiskKV       ~1,147,987 rows   ← almost all of the bytes

cursorDiskKV breakdown by key prefix (SUM(LENGTH(value))):
  agentKv:%        766,699 rows    91.37 GB
  bubbleId:%       355,342 rows     3.95 GB
  checkpointId:%     5,855 rows     0.09 GB
  composerData:%     2,620 rows     0.28 GB
  TOTAL                           ~96.08 GB of stored values

Of agentKv keys, nearly all are agentKv:blob:… (~767k); only 2 are agentKv:artifact:…
  (artifacts point at /opt/cursor/archives/plans/… — tiny, ~17 KB total)

PRAGMA freelist_count ≈ 77 pages → not SQLite free-page bloat; real payload.

Largest individual values sampled were multi‑MB composerData, agentKv:blob:…, and bubbleId:… entries (several in the 4–7 MB range; one composerData ≈ 22 MB).

Separate filesystem agent transcripts under ~/.cursor/projects/*/agent-transcripts are only hundreds of MB total — so most history is inside SQLite, not those folders.

Growth timeline — what we can and cannot prove

Hard size anchors (only two)

There is no Time Machine / no daily size series for this file. The only trustworthy size checkpoints are:

  1. 2026-05-12 22:09 — state.vscdb.backup = 3.06 GB
    (Cursor’s automatic backup of the live DB at that time)
  2. 2026-07-17 — live state.vscdb = 97.09 GB

So we can say with certainty:

  • On 12 May the DB was already large (~3 GB), but still within the “known painful” range from other reports.
  • By 17 July it had become ~97 GB (+94 GB).
  • Average rate over that interval ≈ 1.4 GB/day, which is consistent with other “~1 GB/day” forum reports under heavy Agent use.

We cannot claim a single calendar day when the file size jumped 10→50→97 GB, because no intermediate size snapshots exist.

Activity proxy (composer session creation) — best signal for when intensity rose

Using composerHeaders.createdAt as a proxy for Agent/chat session creation (session counts, not bytes per session):

Weekly composers (Apr–Jul 2026):

Week starting Composers Subagents Main agents
2026-04-06 108 68 40
2026-04-13 150 86 64
2026-04-20 165 121 44
2026-04-27 54 29 25
2026-05-04 253 189 64
2026-05-11 95 60 35
2026-05-18 267 125 142
2026-05-25 202 29 173
2026-06-01 110 60 50
2026-06-08 170 42 128
2026-06-15 102 42 60
2026-06-22 170 96 74
2026-06-29 405 111 294
2026-07-06 227 58 169
2026-07-13 68 47 21

Sharpest activity increase: the week of 29 Jun – 5 Jul 2026 (405 new composer sessions — roughly 2× the prior busy weeks).

Peak single day: 2026-07-01 with 119 new composer sessions (35 subagents).

Daily peak window (early July):

Day Composers Subagents
2026-07-01 119 35
2026-07-02 55 15
2026-07-03–11 10–83/day varying
2026-07-12–17 1–20/day mostly subagents

Possible trigger: Cursor for iOS public beta + “My Machine” / local workers (29 Jun 2026)

I set up My Machine / local agent workers around the phone-app launch. The public dates and local filesystem evidence line up tightly:

Event When
Cursor for iOS public beta announced 29 Jun 2026 (blog, changelog)
First cursor-agent-worker-*.log on this Mac 29 Jun 22:18
com.cursor.local-agent-workers LaunchAgent created (KeepAlive + RunAtLoad) 29 Jun 22:54
Composer session spike week of 29 Jun; peak day 1 Jul

Workers were registered for several repos. That LaunchAgent is unloaded / deactivated now (no worker processes running).

Important: local workers did not store the 97 GB themselves

I checked whether the worker subprocesses were the disk sink for the giant DB. They are not.

Worker-related disk (separate from state.vscdb), ~7.3 GB total:

Location Size Notes
Two worker logs (…5f95884d95.log, …7e19340c59.log) ~5.7 GB Verbose INFO Session / Stream text; born 29–30 Jun
Other worker logs ~tens of MB Same pattern
anysphere.cursor-agent-worker/agent-cli version caches ~1.5 GB 9 CLI bundles (~170–200 MB), versions 19 Jun – 16 Jul
~/.local/share/cursor-agent ~160 MB Runtime
LaunchAgent logs ~24 KB Negligible

Evidence workers are not writing into state.vscdb directly:

  • Worker IDs from those logs appear 0 times in cursorDiskKV keys and composerHeaders values.
  • Worker log contents do not mention state.vscdb / agentKv / bubbleId.
  • The 97 GB remains almost entirely anonymous agentKv:blob:… hashes inside the desktop global DB.

Inference on causality (careful)

  1. Byte growth from May → July is real and severe (3.1 → 97 GB), dominated by agentKv:blob.
  2. The strongest session-creation spike is late June / early July (week of 29 Jun; peak day 1 Jul) — the same window as iOS launch + My Machine setup on this Mac.
  3. Plausible mechanism: My Machine / phone-driven / always-on local workers increased Agent traffic; the desktop Cursor app then persisted that history into unbounded agentKv (indirect accelerator). This is correlation + mechanism fit, not a proven byte-level spike day.
  4. Not plausible: that the worker log/CLI folders are the 97 GB. Those are a separate ~7 GB problem.
  5. Mid-July (12–16 Jul) was a heavy local disk period for project worktrees / temp jobs on this machine, but new composer counts were comparatively low then — so the DB size is better explained by sustained Agent KV retention from May onward, with an activity surge around 29 Jun–1 Jul, than by a unique mid-July DB event.
  6. Because the May 12 backup is only 3.1 GB, most of the +94 GB accumulated after 12 May — My Machine may explain acceleration after 29 Jun, but not the pre-existing 3 GB baseline.

Rough mental model:

  • Before / around 12 May: DB already ~3 GB.
  • Mid-May → late June: continued accumulation under steady-high session rates.
  • 29 Jun evening: My Machine / local workers enabled (iOS public beta day).
  • ~29 Jun – early Jul: clearest activity spike; highest-probability window for a steeper byte-growth phase.
  • By 17 Jul: 97 GB in state.vscdb (~91 GB agentKv), plus ~7 GB leftover worker logs/CLI caches (workers now off).

Steps to Reproduce

It is highly unlikely that you either want or can reproduce this properly. However, here is a machine-written suggestion for doing so. I think it would be absurd to do so, but this field is required:

  1. Use Agent mode heavily across multiple large repositories over several weeks (including many subagents).
  2. Optionally enable My Machine / local agent workers (e.g. after Cursor for iOS) so agents can run on the Mac from phone/cloud.
  3. Do not prune chat/agent history (no automatic retention appears to run).
  4. Observe ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb and compare against state.vscdb.backup after Cursor writes a backup.
  5. Optionally inspect:
sqlite3 "$HOME/Library/Application Support/Cursor/User/globalStorage/state.vscdb" \
  "SELECT
     CASE
       WHEN key LIKE 'agentKv:%' THEN 'agentKv'
       WHEN key LIKE 'bubbleId:%' THEN 'bubbleId'
       WHEN key LIKE 'checkpointId:%' THEN 'checkpointId'
       WHEN key LIKE 'composerData:%' THEN 'composerData'
       ELSE 'other'
     END AS cat,
     COUNT(*),
     ROUND(SUM(LENGTH(value))/1024.0/1024.0/1024.0, 2) AS gib
   FROM cursorDiskKV
   GROUP BY 1
   ORDER BY gib DESC;"

Expected Behavior

  • Agent/chat persistence should not grow without bound on disk.
  • There should be automatic retention / compaction, or a first-class UI control to prune old Agent KV safely.
  • Enabling My Machine / local workers should not imply multi‑GB verbose worker logs with no rotation, or unbounded agentKv growth in the desktop DB.
  • A 3 GB → 97 GB climb over ~2 months (with ~1.4 GB/day average) should be treated as a product bug / missing retention policy, not normal “just how SQLite works.”

Operating System

MacOS

Version Information

Version: 3.12.17 (Universal)
VS Code Extension API: 1.128.0
Commit: 0fb762053c34788bb7760d5673f8a6d4c8589d50
Date: 2026-07-17T02:53:53.006Z
Layout: Agent Window
Build Type: Stable
Release Track: Nightly
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

For AI issues: add Request ID with privacy disabled

The request ID of the chat I used to investigate this issue: 6bd876d2-010a-4444-b6fd-6fbee4203c1b

Additional Information

  1. Can you confirm whether ~97 GB / ~1.4 GB/day is within any expected envelope, or should this be treated as pathological retention?
  2. Is growth after enabling My Machine / local workers (esp. with Cursor for iOS) a known amplifier for agentKv retention?
  3. Is there a supported way to prune agentKv without breaking chat loading for keep-worthy conversations?
  4. Are there plans for automatic retention / size caps / background compaction — and for worker log rotation?
  5. If useful for debugging: I can provide additional read-only aggregates (top workspaces by composer count, largest key samples, worker timeline) — prefer not to upload the full 97 GB DB.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

7

Hi @user691 thanks for the post, and for the detailed breakdown. Let me go through each part one by one.

1. Is ~97 GB / ~1.4 GB/day expected? It’s on the extreme end, but it lines up with a known limitation rather than “just how databases work.” Right now Cursor doesn’t automatically clean up or compact the chat and agent history it saves locally, so if you keep your conversations, that history keeps growing, especially with heavy use across many repos and lots of sub-agents. So this is real saved history, as you correctly found, not wasted empty space, and it’s something we’re aware of.

2. Are My Machine / local workers an amplifier? Not really. The local workers don’t write into that database at all, and there’s no worker-specific storage behavior, so turning them on isn’t a separate cause of the growth. The timing lines up simply because you were running more agent sessions during that stretch, and any heavy agent use (workers or not) produces more saved history. So the real driver is the desktop app storing all that chat history plus your overall agent volume, not the workers themselves. Two quick side notes: very heavy sub-agent use (agents that spawn copies of themselves) can multiply the number of saved records, and those large worker log files are a separate disk issue.

3. A supported way to prune without breaking chat loading? Yes, and please don’t delete or rename the database file itself (that’s what causes the endless “Loading Chat”). Instead, open the Command Palette and use these built-in commands:

  • Developer: Delete Old Chats... asks how many days of history to keep (default 30), removes chats you haven’t touched since then, then clears the now-unused history and compacts the file to hand the space back, and offers a Reload Window at the end.
  • Developer: GC Agent KV Blobs does that same cleanup and compaction without deleting any chats. It only clears leftover data that’s no longer attached to any conversation, so it’s safe, but it won’t shrink a database that’s mostly made up of chats you’re keeping.

4. Plans for automatic cleanup, caps, or log rotation? Yes, this is on our radar. There’s already an automatic background cleanup for leftover/unused data, but by design it doesn’t touch history you’re keeping, and on older databases it can’t return the freed space on its own (which is why the manual compaction command exists). Proper automatic cleanup of kept history, the reclaim-reliability fix above, and the noisy worker logs are all understood on our side and being worked on. I can’t promise specific dates, but none of this is new to us.

5. Additional details. No need to upload the 97 GB file. If the cleanup above doesn’t free much, the most helpful thing to share is the summary line the cleanup command shows when it finishes (it reports how many entries were total, still in use, and deleted). It will look something like this:

Deleted 24 chat(s) older than 60 days in 0.4s. GC complete in 8.3s (GC: 7.5s, VACUUM: 0.8s): 10,226 total, 8,016 live, 2,214 deleted

Bottom line: run Developer: Delete Old Chats... with the days setting of your choice, and let us know how this goes!

8

Thanks a lot for taking the time to write such a detailed answer and explanation, Kevin! I will try your suggested solution in the upcoming days and report back on how it went. I actually used commands with a lot of sub-agents recently so that has likely added to the usage of storage.