Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
All 132 agent chats vanished from the sidebar after the auto-update from 3.13.10 to 3.13.21. Unlike most reports of this class, no state.vscdb.corrupted.* rescue file was created, so the standard recovery (rename the corrupted file back to state.vscdb) is unavailable to me.
The logs show exactly what happened. From the pre-update session log:
2026-07-28 07:48:21.371 [info] UpdateService onUpdateDownloaded()
2026-07-28 07:48:22.345 [info] update#setState ready
2026-07-28 09:48:58.121 [info] [UpdateSupervisor] Snapshotting before quit (enabled=false)
2026-07-28 09:49:00.786 [error] [storage state.vscdb] exec(): Error: SQLITE_IOERR_TRUNCATE: disk I/O error
2026-07-28 09:49:00.833 [info] UpdateService doQuitAndInstall()
SQLite’s final flush of state.vscdb failed with a disk I/O error, and Cursor called doQuitAndInstall() 47 ms later without preserving the database or deferring the update.
From the post-update session log:
2026-07-28 09:49:59.935 [info] updateURL …/cursor/3.13.21/…
2026-07-28 09:50:03.642 [info] [LocalAgentStorage] Scanned 4 recent databases (skipped 14 old), found 0 agent headers, deduped to 0
The same line from the two prior startups on 3.13.10:
2026-07-25 08:17:15.432 [info] [LocalAgentStorage] Scanned 2 recent databases (skipped 15 old), found 132 agent headers, deduped to 132
2026-07-26 21:38:39.639 [info] [LocalAgentStorage] Scanned 3 recent databases (skipped 15 old), found 132 agent headers, deduped to 132
state.vscdb has a filesystem birth timestamp of 09:49:58 — created fresh by the new version, not migrated.
What I believe are the actual bugs
The corruption-preserve path did not fire. Cursor logged the I/O error itself, so it knew the write had failed, yet produced no state.vscdb.corrupted.* file. Every other report of this class has that file and recovers from it. Without it there is no recovery path at all.
state.vscdb.backup was overwritten with the post-reset empty state at 09:50:16, about 18 seconds after the new empty DB was created. A backup should not be clobbered by a database that was just detected as unreadable — that removes the second line of defence.
The update proceeded despite a known-failed database write. A storage error 47 ms before doQuitAndInstall() seems like a reasonable trigger to defer the update or force a preserve-and-copy first.
Things I can rule out
Not low disk space. 154 GB free of 460 GB (8% used). This is the cause usually cited in similar threads, so I checked it first.
Not failing hardware. SSD reports SMART status Verified; no kernel I/O errors in the system log that day.
Not a workspace-identity change. New chats land in the same ~/.cursor/projects// folder as the old ones, and the workspace storage directory is the same one from February.
Not a recurring fault. SQLITE_IOERR_TRUNCATE appears exactly once in my entire Cursor log history going back to 2026-07-09.
Screenshots / Screen Recordings
None. Log excerpts above; full log files available on request.
For AI issues: which model did you use?
Two changes would each have made this a non-event:
Guarantee a state.vscdb.corrupted.* copy whenever a storage exec() error is logged, before any update install, and never overwrite state.vscdb.backup afterwards.
The reimport-from-transcripts capability already being tracked in the thread above.
Does this stop you from using Cursor?
Steps to Reproduce
The triggering condition is a transient disk write failure at the moment of the update shutdown, which is hard to force on demand. The deterministic part is the handling:
Have Cursor download an update and reach update#setState ready.
Cause exec() on globalStorage/state.vscdb to fail during the quit-to-install flush (in my case a spontaneous SQLITE_IOERR_TRUNCATE).
Cursor installs the update regardless.
On next launch it creates an empty state.vscdb, loads 0 agent headers, and leaves no state.vscdb.corrupted.* behind.
Expected Behavior
When a storage exec() error is logged for state.vscdb, Cursor should preserve the existing database as state.vscdb.corrupted. (or abort the update) before installing. It should never overwrite state.vscdb.backup with a database created after a corruption event. Chat history should survive the update, or at minimum remain recoverable.
Operating System
MacOS
Version Information
macOS (26.5.2, build 25F84, Apple Silicon / arm64)
Version Information
Version: 3.13.21
VSCode Version: 1.128.0
Commit: 55434bd8062ece6fee083b82beed2aee42d253f0
Date: 2026-07-27T03:26:14.573Z
OS: Darwin arm64 26.5.2
Updated from: 3.13.10 (the update during which the loss occurred)
For AI issues: which model did you use?
Not applicable — no model request involved.
For AI issues: add Request ID with privacy disabled
Not applicable — no model request involved.
Additional Information
The transcripts are intact at ~/.cursor/projects//agent-transcripts//.jsonl — 130 for the affected project predating the update, 153 unique across all projects, the oldest from 2026-02-19. I can read them directly, so nothing is truly lost — but per the staff reply on Agents sidebar empty — 222 transcripts still on disk (Windows) there is currently no way to rebuild the sidebar from them.
Does this stop you from using Cursor
No - Cursor works, but with this issue