This is something we’ve seen before with heavy Composer usage on macOS. There are a couple of known bugs that can cause the crashes you’re describing, and we need a bit of diagnostic info to narrow down which one is affecting you.
Could you check two things for me?
1. Your state.vscdb file size:
ls -lh ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb
If this file is larger than 1-2 GB, that’s likely the root cause.
2. Developer Console errors (if you can catch one before it crashes): Open Help > Toggle Developer Tools, then go to the Console tab. Look for any [storage] Item exceeds IPC threshold warnings. If you see those, it points to a specific storage bloat issue.
In the meantime, here’s a workaround that fixes the most common variant of this crash:
-
Fully quit Cursor (Cmd+Q)
-
Back up your database (just in case):
cp ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb ~/state.vscdb.backup
- Clear the problematic storage key:
sqlite3 ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb "DELETE FROM ItemTable WHERE key LIKE 'composer.composerHeaders%';"
- Restart Cursor
The chat sidebar will appear empty, but your chats are stored separately and should load back.
Fair warning: with very heavy Composer usage, this key can rebuild to the crash threshold within 30 minutes to an hour. If that happens, you can save the cleanup as a shell alias to make it quicker. Add this to your ~/.zshrc:
alias cursor-fix='osascript -e "quit app \"Cursor\"" && sleep 2 && sqlite3 ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb "DELETE FROM ItemTable WHERE key LIKE '\''composer.composerHeaders%'\'';" && open -a Cursor'
Then run cursor-fix whenever it crashes again.
The underlying storage bug is tracked and being worked on. You may also find this related thread helpful - it covers the same issue with more detail on the workaround.
Regarding the “burning credits” concern: when the app crashes mid-run, the agent work up to that point is lost. Starting a new chat after restarting is the safest approach until the fix ships.
Let me know the state.vscdb file size and whether the workaround helps!