A clear and concise description of what the bug is.
Deleting the global ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb (and backup) file — as commonly recommended in community advice for cleaning up massive disk usage (e.g., 14+ GB per file) — causes existing project chat histories to get stuck in an infinite “Loading Chat…” state. No chats load, the sidebar shows placeholders but clicking them does nothing or stays frozen indefinitely.
Restoring the original state.vscdb files immediately fixes the loading issue, confirming the data itself is not lost — but this defeats the purpose of cleaning up space. The problem seems related to global indexes/references (e.g., chat handles, composerData, bubbleId, or allComposers lists) being reset without proper rebuild from workspace-level databases. This makes the “safe cleanup” advice potentially dangerous for users with heavy chat/Agent/Composer history.
Expected: After deleting global state.vscdb, Cursor should rebuild chat indexes from per-project workspaceStorage/*/state.vscdb files, preserving history and checkpoints without infinite loading.
Actual: Infinite loading loop; no recovery without manual restore of the old global DB.
Steps to Reproduce
Export profile (Cmd+, → Profiles → Export Profile) to backup settings/extensions/keybindings.
Fully close Cursor (confirm no processes in Activity Monitor).
Delete global state files:Bashrm ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb*
Restart Cursor and open an existing project with prior chat history.
Go to Chat sidebar → Try to load/click any previous conversation.
→ Result: Stuck on “Loading Chat…” forever (no progress, no error message).
(For verification) Restore original state.vscdb files → Restart → Chats load normally again.
Expected Behavior
Chat history should reload by scanning/rebuilding from workspaceStorage databases.
Or at minimum, provide a warning/error that global DB deletion may affect chat loading, and offer a rebuild option.
Hey, thanks for the detailed report. This is a known limitation. The global state.vscdb file stores an index and references that point to your chat data. The actual chat data lives in workspaceStorage databases for each project. Right now, Cursor can’t rebuild that index from workspace-level files after the global DB is deleted, so you end up stuck in an endless “Loading Chat” state.
Your data isn’t lost. It’s still in workspaceStorage/*/state.vscdb, but without the global index the UI doesn’t know where to find it.
Restoring the original file is the only recovery path right now, and you’ve already confirmed that works.
For the disk space issue (14+ GB), you can try running VACUUM on the global file using SQLite while Cursor is fully closed:
This frees unused space caused by fragmentation and deleted records without breaking references. It won’t shrink active data, but it can significantly reduce bloated files.
I’ve shared this with the team, both the missing rebuild mechanism and the lack of built-in cleanup for oversized state files.
I believe it’s opposite, globalStorage’s state.vscdb contains the entire chat data of all workspaces, but “workspaceStorage”s state.vscdb only contains agent conversation titles. Hence why globalStorage’s state.vscdb’s file size is massive.
hence why if you want to migrate to a different device, you need to backup globalStorage’s state.vscdb to get all chat data and the workspaceStorages’ state.vscdb to get all conversation names (the ones you see on the right).
As for agent transcript it’s in
%UserProfile%.cursor\project
Although I never checked the workspace vscdb using sqlite so I may be misunderstanding it
Just tried exporting one of my very long chat history, and I can say for certain it is beyond incomparable to the size of the workspace’s state.vscdb which is just a few mb compared to 800mb of exported chat data from that same workspace.
I tried “deleting” globalStorage’s state.vscdb to start fresh, open up a new folder/project/workspace, tried importing the chat history in that folder and it inflated the conversation to about what my exported conversation’s file size was 800mb.
I used Cursor Chat Transfer extension. Personally forked, built, and installed to increase the 256 max buffer to 1gb so that the ENOBUFS error does not happen when exporting
I tried deleting the conversations after importing in the agents side bar, yet globalStorage’s state.vscdb’s file size did not budge. I would say the exported file is oddly large even if half of the 31 conversations I exported are really long conversations, so this could be some sort of Cursor leak issue.
Furthermore, if you’ve faced crashes when closing and opening Cursor, it means Cursor is trying to routinely backup globalStorage’s state.vscdb to state.vscdb.backup, but you prematurely opened it before it could completely backup, hence the error. Either wait for it to finish by waiting for cursor to disappear in task manager, or end Cursor in task manager to cancel the backup. Might need to delete the .backup file if it crashes still.
