Hey, awesome bug report. The root cause write-up with logs is super helpful.
There are two related issues here, and both are known:
- state.vscdb bloat via cursorDiskKV
This is a known bug. The cursorDiskKV table keeps bubbleId:* records with no limit, and over time the DB can grow to multiple GB. Other users have hit this too:
The team is aware, but there’s no ETA yet for a retention policy. Your workaround of clearing caches and deleting cursorai/serverConfig is basically the best thing to do right now. For a more drastic fix, you can fully recreate state.vscdb:
# Fully quit Cursor
mv ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb.bak
# On next launch, Cursor will create a fresh DB (~188 KB)
Side effect: you’ll lose some settings (trusted folders, etc.), but AI chat will still work.
- No Connect transport provider registered on external volumes
This is an interesting trigger we haven’t seen in this context before. The file watcher refuses to watch /Volumes/… (treats it like a network share), which slows extension host startup, and cursor-always-local doesn’t register the transport before the 2-minute timeout. Combined with a bloated state.vscdb, the timeout is basically guaranteed.
I passed this trigger to the team. Your detailed analysis helps with prioritization.
About the secondary issue with timeouts on very large chats (1000+ messages), that’s also tied to bubble data size in state.vscdb. For now, the best workaround is to start new chats periodically instead of letting a single chat reach thousands of messages.
Let me know if recreating state.vscdb stabilizes things, even if only for a while.