I’m experiencing what appears to be a database compatibility or recovery issue, and I’d really appreciate your help.
After an unexpected problem, Cursor stopped displaying all of my conversations.
Fortunately, I still have a complete backup of the original database.
The main database is:
~/Library/Application Support/Cursor.backup/User/globalStorage/state.vscdb
Its size is approximately 37 GB.
I also have:
conversation-search.db
which still contains the indexed conversation text.
What I’ve verified
The database is not corrupted.
It opens normally with SQLite.
The following tables exist:
ItemTable
cursorDiskKV
composerHeaders
The search database also opens correctly and contains:
conversations
conversation_fts
conversation_fts_content
conversation_fts_idx
…
What I found
The original database contains approximately:
- 1,142 composerData:* records
- ~850,000 bubbleId:* records (about 7 GB of message data)
- many agentKv:blob:* records, some larger than 100 MB
The message data clearly still exists.
Recovery attempts
I wrote scripts to inspect the database and verified that:
- conversation metadata (composerData) is present
- message records (bubbleId) are present
- agent blobs are present
I also restored these records into a clean Cursor profile.
The result is interesting:
- conversation titles appear correctly
- folders appear correctly
- the message bodies are empty
This strongly suggests that Cursor expects additional internal structures or references that I have not yet identified.
conversation-search.db
The search database still contains the conversation text.
For example:
System functionality analysis
…
Found Evolution running on the VPS.
System returned to Evolution.
…
So the content itself still exists.
My request
Could you please help me understand:
- Which records are required for Cursor to reconstruct a conversation?
- Besides composerData and bubbleId, which internal keys or structures are necessary?
- Are there hidden indexes, manifests, graphs, checkpoints or metadata required?
- Is there an official recovery procedure for an existing state.vscdb?
- Can conversation-search.db be used to rebuild the original database?
- Has the internal database format changed recently?
I am not asking for unsupported data recovery.
I already possess the original database and its complete backup.
I’m simply trying to restore Cursor’s ability to read its own database.
If helpful, I can provide:
- SQLite schema
- sample records
- database statistics
- key prefixes
- diagnostic scripts
- any additional information you need
I’d really appreciate any technical guidance from the engineering team.
Thank you very much for your help.
Best regards,
Marcelo Marchis
Steps to Reproduce
-
Cursor unexpectedly lost all conversation contents while the database files remained intact.
-
I restored my original backup located at:
~/Library/Application Support/Cursor.backup/
-
The original database (User/globalStorage/state.vscdb) is approximately 37 GB and opens successfully with SQLite.
-
I verified that the database still contains:
- composerData records
- bubbleId records
- agentKv blobs
- conversation metadata
-
I also verified that conversation-search.db still contains the indexed conversation text.
-
I restored the required records into a clean Cursor profile.
-
After restarting Cursor, conversation titles and folders appear correctly, but opening any conversation shows an empty chat.
Expected Behavior
Cursor should be able to read its own original database and reconstruct all conversations.
The original state.vscdb still contains the conversation metadata, hundreds of thousands of message records, and large agent blobs.
Conversation titles appear correctly, which indicates that the metadata is valid. The expected behavior is that Cursor also reconstructs and displays the complete conversation contents instead of showing empty chats.
Operating System
MacOS
Version Information
Version: 3.11.19 (Universal)
VS Code Extension API: 1.125.0
Commit: bf249e6efb5b097f23d7e21d7283429f0760b740
Date: 2026-07-12T21:39:24.175Z
Layout: Agent Window
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.256
OS: Darwin arm64 25.5.0
For AI issues: which model did you use?
Not applicable.
This is not an AI model issue.
This is a Cursor IDE database recovery / conversation loading issue.
For AI issues: add Request ID with privacy disabled
N/A
Additional Information
Additional technical findings:
- Original database size: ~37 GB
- Database opens normally in SQLite
- cursorDiskKV contains approximately:
- 1,142 composerData records
- ~850,000 bubbleId records
- multiple large agentKv:blob records (up to 118 MB)
conversation-search.db still contains the indexed conversation text.
I verified that the original conversation contents still exist.
I also attempted to restore composerData, bubbleId and related records into a clean Cursor profile.
Result:
- Conversation titles appear correctly.
- Conversation bodies remain empty.
This suggests Cursor expects additional internal structures or references that are not documented.
I would greatly appreciate engineering guidance regarding which internal records are required for Cursor to reconstruct conversations from an existing state.vscdb database.
Does this stop you from using Cursor
Yes - Cursor is unusable