Update wiped agent chat history (cursorDiskKV) — Agents Window empty, restore crashes

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After updating Cursor to 3.16.29 on macOS (Darwin 25.6.0, arm64), my entire local agent chat history became unusable:

  • Agents Window showed no (or almost no) past agents
  • Opening old chats showed empty content
  • SQLite DB ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb lost ~6 GB of cursorDiskKV blob data (chat messages), shrinking from ~6 GB to ~10 MB
  • Index tables were corrupted too (glass.localAgentProjectMembership.v1: 0 entries; composerHeaders: 7 instead of 200+)

Silent data loss with no warning, no migration, no in-app recovery. Attempting to restore the backup blobs crashes Cursor completely.

This is extremely user-unfriendly for anyone relying on agent history for long-running projects.

Steps to Reproduce

  1. Use Cursor Agents heavily over weeks/months (macOS)
  2. Auto-update to Cursor 3.16.x
  3. Open Agents Window (Cmd+Shift+P → Open Agents Window) → history empty or incomplete
  4. Inspect state.vscdb: cursorDiskKV dropped from ~197,000 entries / 6 GB to ~400 entries / 10 MB
  5. Try restoring cursorDiskKV from pre-update backup → Cursor crashes

Expected Behavior

  • Updates migrate local agent data, never delete it silently
  • Clear warning if migration fails
  • Built-in repair/export tool
  • Chat history remains readable after updates

Operating System

MacOS

Version Information

Version: 3.16.29 (Universal)
VS Code Extension API: 1.128.0
Commit: 6246455961129c32969845e00aa25d87ae926ec0
Date: 2026-08-18T01:26:26.285Z
Layout: IDE
Build Type: Stable
Release Track: Default
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.291
OS: Darwin x64 25.6.0

Additional Information

  • Path: ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb
  • Table: cursorDiskKV (composerData:, bubbleId:)
  • Before: ~6.2 GB / ~197k entries
  • After: ~12 MB / ~400 entries
  • JSONL sidecars on disk: 151 files / 21.6 MB (partial recovery only)

Suggestions for Cursor team:

  1. Never delete cursorDiskKV without explicit consent
  2. DB migrations with rollback
  3. Use JSONL transcripts as source of truth; auto-rebuild UI index
  4. Add Help → Repair Agent History (safe, metadata-only)
  5. Document storage location and backup

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report. Good news: your original ~6.2 GB database is most likely still there. When Cursor can’t open state.vscdb, it renames the file instead of deleting it. This shouldn’t happen, and it’s not something in your setup. Let’s try to restore it.

    1. Fully quit Cursor.
    1. Open ~/Library/Application Support/Cursor/User/globalStorage/ and look for a file like state.vscdb.corrupted.<timestamp>. That’s your original database, just renamed.
    1. Check its integrity:
    sqlite3 state.vscdb.corrupted.<ts> "PRAGMA integrity_check;"
    1. If it returns ok: back up the current small state.vscdb, delete state.vscdb-wal and state.vscdb-shm, copy the corrupted file back as state.vscdb, then start Cursor and give it time. A multi‑GB DB can open slowly on 3.16.x. That slow open is likely what caused your crash during restore. Wait longer before assuming it’s stuck.
    1. If integrity_check shows malformed:
    sqlite3 state.vscdb.corrupted.<ts> ".recover" | sqlite3 recovered.vscdb
    Then use recovered.vscdb as state.vscdb.

Your JSONL sidecars 151 files are only a partial transcript. You can’t fully rebuild the UI from them right now, so the main bet is state.vscdb.corrupted.<ts>.

For next time, to reduce risk: keep the DB smaller using Developer: GC Agent KV Blobs and Delete Old Chats via Cmd+Shift+P, and if possible, copy state.vscdb before big updates.

I’ve shared this with the team. Let me know if you found state.vscdb.corrupted.<ts> and whether the restore worked. If anything goes wrong, we’ll dig in further.