Hey, thanks for the detailed report. The crash stack is very clear. This looks like a known issue where state.vscdb grows without bounds in the cursorDiskKV table. What’s unique in your case is that the DB got so large that macOS detected a sustained write rate and killed the process due to disk write throttling. The stack trace being 100% in SQLite WAL frame commits via vscode-sqlite3.node matches that.
We’re tracking this on our side, but I can’t share an ETA for a fix yet. The root cause is that key prefixes like agentKv, bubbleId, aiCodeTrackingLines, and composer.composerHeaders keep accumulating with no retention or GC.
What you can do right now:
- Check the size of
~/Library/Application Support/Cursor/User/globalStorage/state.vscdb. If it’s multiple GB, close Cursor and delete the file. Also deletestate.vscdb.backupnext to it. After you restart, Cursor will recreate the DB from scratch. Downside: you’ll lose local chat and composer history. Upside: the write storm should stop until the DB grows again. - After updating to 3.4.17, it looks like your DB effectively reset back down, so things are quiet for now. It’s still worth checking the file size from time to time.
Related threads with workarounds:
- Cursor state.vscdb growing at 1 GB in a day
- Best practices with state.vscdb and state.vscdb.backup in Cursor
I’ll link this thread to our internal tracker as extra evidence. The macOS throttle and kill scenario is a very useful signal. If it happens again on 3.4.17, reply here with the new state.vscdb size and the incident time window.