Cursor globalStorage bloat

Louis Laugesen · December 9, 2025

I was seeing a CPU core pegged and Cursor was continuously crashing out in various ways.

Something like this node.mojom.NodeService was showing up in top with 100-200% CPU usage:

code --type=utility --utility-sub-type=node.mojom.NodeService --lang=en-US --service-sandbox-type=none --no-sandbox ...

What I tried? Oh the usual stuff, sandbox mode, disabling extensions, removing extensions, rebooting, trying a different workspace, googling around aimlessly, consulting chatgpt, trawling through bug reports on Cursor community forums, disabling VPN, enabling VPN, changing VPN servers, running Cursors network diagnostic tool, downgrading Cursor, re-installing electron. The shotgun list truly goes on and on.

What was it in the end?

Ever left your browser history age a little too long and / or something got corrupted in it?

Cursor has something similar stashed away in the globalStorage state db. Typically this will be located at ~/.config/Cursor/User/globalStorage/state.vscdb.

I found this looking through ~/.cache, and ~/.config with find to pick out any larger looking files that might be corrupted, fragmented, or sucking on node_modules somehow. I found a state.vscdb file at 602M. That kind of size in a .config directory is more than suspicsious enough to warrant some investigation.

ls -alh ~/.config/Cursor/User/globalStorage/state.vscdb
-rw-r--r-- 1 louis louis 602M Dec  9 22:03 /home/louis/.config/Cursor/User/globalStorage/state.vscdb

Moving this file (and it's .backup variant) to something like state.vscdb.bk instantly resolved the CPU pegging issue.

The problem?

Well, that state.vscdb living in ~/.config contains all your application configuration settings, Cursor login session, Cursor settings, memory options, command whitelist and various other options you probably want to keep.

There doesn't seem to be an easy way to export these options to file for import later. (e.g. like how you can import from vscode)

At this moment I had two options: copy paste all my "memories" and take a video recording of all my settings, including the list of whitelisted commands I'd need to write back in one by one.

Or:

Figure out how to uncorrupt state.vscdb...

So what exactly is state.vscdb anyway?

less ~/.config/Cursor/User/globalStorage/state.vscdb
SQLite format 3^@^P^@^Z^B^@@  ^@^OY<E9>^@^@4<C8>^@^@5f^@^@^AF
...

SQLite! Great, what do we see in there?

cd ~/.config/Cursor/User/globalStorage
sqlite3 state.vscdb
SQLite version 3.51.1 2025-11-28 17:28:25 Enter ".help" for usage hints.
sqlite> .tables ItemTable cursorDiskKV
sqlite> SELECT COUNT(*) FROM ItemTable;
376
sqlite> SELECT COUNT(*) FROM cursorDiskKV;
50023

So, I guess 50k rows in cursorDiskKV is going to be where that 600mb is coming from.

Selecting from both of these via cli wasn't super helpful - lots of json objects.

cursorDiskKV seems to hold cursor chat logs.

ItemTable seems to hold smaller objects and going by the keys looks like where my Cursor settings are stored (that is, not the "editor settings" stored in json files by the vscode part of the IDE).

Opening up the sqlite database in Beekeeper studio let me browse more easily and I was able to confirm the options I cared about (memories etc) were in ItemTable and that cursorDiskKV looked more like a workspace key value store or some kind of chat history dumping ground.

At this point I had enough information to move ahead with a cleanup and see if anything breaks:

sqlite3 state.vscdb
DELETE FROM cursorDiskKV;
VACUUM;
.exit
cp state.vscdb state.vscdb.backup

This deletes everything from cursorDiskKV and runs a vacuum on the database to bring the filesize back in line.

The copy command to overwrite state.vscdb.backup may or may not be necessary, I suspect that file is created as a backup on startup or shutdown, it seemed to match filesize (exactly) so I figured copying over it withe the clean version won't have any negative side effects and will prevent any self healing that might bring the corruption back.

My new, clean globalStorage/state.vscdb is now checking in at a lean 54M:

-rw-r--r-- 1 louis louis 54M Dec 9 23:45 /home/louis/.config/Cursor/User/globalStorage/state.vscdb

And the CPU core pegging issue is resolved.

Conclusion

I love seeing SQLite being used for this kind of applicaton, a proprietary binary format would have been nearly impossible to clean up.
This cursorDiskKV table really shouldn't be under ~/.config. It would be best to the table to a separate sqlite databse under ~/.cache or ~/.local/share leaving ItemTable in the existing db under ~/.config. The ~/.cache and ~/.local/share directories are typically safe to delete the contents of without losing your application settings.
If cursorDiskKV was in ~/.cache or ~/.local/share I would have had this problem resolved in 5 mintues with a "backup and restart without it" test. Mixing config values in with application data turned it into more of an ordeal than it needed to be.