Cursor Chat History Disappeared: How to Get It Back

Before anything else: do not reinstall Cursor, do not clear application data, and do not delete anything in the globalStorage folder. Most of the ways this goes permanently wrong start with a reinstall performed in the first five minutes. Your conversations are probably still on disk.

There are four causes, and they need different fixes. Work out which one you have first — the whole thing takes about a minute.

Step 1: look at what is on disk

Quit Cursor completely, then list the storage directory. What you see there tells you which situation you are in:

# macOS
ls -la ~/Library/Application\ Support/Cursor/User/globalStorage/ | grep state.vscdb

# Windows (PowerShell)
dir $env:APPDATA\Cursor\User\globalStorage\state.vscdb*

# Linux
ls -la ~/.config/Cursor/User/globalStorage/ | grep state.vscdb

On the machine used for this article the listing shows four files: state.vscdb at 6.8 GB, state.vscdb.backup at 2.9 GB, plus the -wal and -shm journal files. That backup is written by Cursor itself, most people never learn it exists, and it is the first thing to reach for.

• You see a file named state.vscdb.corrupted.<numbers> → go to Fix A. This is the good case: your data is in that file.
• state.vscdb is present and normal-sized, but a project you renamed or moved shows an empty chat panel → Fix B.
• state.vscdb is present but Cursor hangs on "Loading Chat", or shows nothing at all → Fix A, then Fix C.
• state.vscdb is missing or tiny (a few hundred KB) and there is no .corrupted file → Fix D, and read the last section.

Fix A — the corrupted file is your data

When Cursor finds the database unreadable it does not delete it. It renames it to state.vscdb.corrupted.<timestamp> and starts a fresh, empty one — which is why the app opens with no history while the history sits in the same directory under a different name. Cursor will not restore it for you.

cd ~/Library/Application\ Support/Cursor/User/globalStorage/

# 1. quit Cursor first, then park the current files
mkdir -p OLD && mv state.vscdb state.vscdb.backup state.vscdb-wal state.vscdb-shm OLD/ 2>/dev/null

# 2. promote the corrupted file back to the real name
mv state.vscdb.corrupted.* state.vscdb

# 3. reopen Cursor

Move, do not delete. If this does not work you want the originals back, and the OLD folder is how you get them. If there are several .corrupted files, try the largest first — it is usually the most complete.

If there is no .corrupted file but there is a state.vscdb.backup, the same procedure applies with the backup: park the current database and rename the backup into its place. It is an older snapshot, so expect to lose recent conversations rather than all of them.

Fix B — you renamed or moved the project

Cursor stores per-project state in a directory named after a hash of the project's path. Rename the folder, move it, or open it through a symlink or a different mount, and Cursor computes a different hash and opens a workspace with no history. Nothing was deleted; the link was.

W=~/Library/Application\ Support/Cursor/User/workspaceStorage

# find the directory that still points at the old path
grep -l "old-project-name" "$W"/*/workspace.json

# and the one for the new path
grep -l "new-project-name" "$W"/*/workspace.json

The simplest fix is to move the project back to its original path and open it there — the hash matches again and the history returns. If moving it back is not an option, copy the contents of the old workspace directory into the new one with Cursor closed.

Fix C — read the conversations out of the database yourself

This is the part worth knowing even when nothing is broken: the conversations are in an ordinary SQLite database, and you can read them without Cursor's help. If the app will not display your history, this still works.

Cursor stores each message as a JSON row in a table called cursorDiskKV, keyed bubbleId:<conversation>:<message>, with the conversation metadata under composerData:<conversation>. Start by listing your conversations by name:

DB=~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb

sqlite3 -readonly "$DB" \
  "SELECT substr(key,14), json_extract(value,'\$.name')
     FROM cursorDiskKV
    WHERE key LIKE 'composerData:%'
      AND json_extract(value,'\$.name') IS NOT NULL;"

That prints a conversation id and its title. Take the id of the one you want and dump it to markdown — type 1 is you, type 2 is Cursor, and createdAt puts the messages back in order:

C=<paste-the-conversation-id-here>

sqlite3 -readonly "$DB" \
  "SELECT CASE json_extract(value,'\$.type')
            WHEN 1 THEN '## You' ELSE '## Cursor' END
          || char(10) || json_extract(value,'\$.text')
     FROM cursorDiskKV
    WHERE key LIKE 'bubbleId:$C:%'
      AND ifnull(json_extract(value,'\$.text'),'') <> ''
    ORDER BY json_extract(value,'\$.createdAt');" > conversation.md

Run against the database on this machine, that query turned one conversation into a 40,000-line markdown file. It is the export button Cursor does not have, it works on a database the app refuses to open, and it works on the .corrupted file too — point DB at that filename instead.

If sqlite3 itself reports the file as malformed, recover what is readable first, then query the recovered copy:

sqlite3 "$DB" ".recover" | sqlite3 recovered.db
sqlite3 -readonly recovered.db "SELECT COUNT(*) FROM cursorDiskKV;"

Fix D — when it really is gone

If the database is missing or empty and there is no .corrupted file and no .backup, the honest answer is that it is not recoverable from Cursor. There is no trash folder and no server-side copy of your chat history to restore from. Two things are still worth trying: your operating system's own backup (Time Machine on macOS, File History on Windows, a snapshotting filesystem on Linux) has the file if it ran, and undelete tools occasionally recover a recently deleted SQLite file if you stop writing to the disk now.

That is the whole recovery story, and it is worth being blunt about it: this is a category where the recovery options are thin, because nothing in the product is designed on the assumption that the history matters.

Stop it from happening again

Three things, in order of how much they buy you:

• Back up state.vscdb on a schedule. With Cursor closed, cp is fine; while it is running, use sqlite3 "$DB" ".backup 'somewhere/state.vscdb'" so you get a consistent copy.
• Copy the workspace directory before you rename or move a project. That is the moment Fix B becomes necessary, and it is entirely avoidable.
• Watch the size. A multi-gigabyte state database is the condition under which corruption reports appear, and it is also what makes Cursor slow to start.

If you would rather not be the person who remembers to do this, that is what PromptWake was built for: it reads what Cursor and the other AI tools already write to disk, keeps prompt, response and the resulting diff locally by default, and on the paid tiers syncs them into one timeline that does not depend on a single SQLite file surviving. Run promptwake doctor first if you just want to know what is currently at risk on your machine — it needs no account and writes nothing.