Cursor history: reviewing an incident

Which change caused this, and why did it look correct at the time?

Why this is hard

Git answers the first half of an incident question. The second half — what the author was trying to do, what constraint they gave the model, what the model quietly worked around — is in the conversation, and it is the half that stops the same failure recurring.

What Cursor specifically does to you here

You can query straight to the conversation that mentions the failing code, which is fast when it works. What the database does not hold is a reliable link from a message to the exact lines that landed in the repository, so the last step is manual.

sqlite3 -readonly "$HOME/Library/Application Support/Cursor/User/globalStorage/state.vscdb" "SELECT COUNT(*) FROM cursorDiskKV WHERE key LIKE 'bubbleId:%';"

Where Cursor keeps this in the first place: ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb. One SQLite file holds every conversation. Corruption, an upgrade, or a cleanup takes all of it at once.

What a working answer looks like

A working answer means going from a line of code to the prompt that produced it, months later, without depending on anyone's memory.

Start by measuring what you have. npx promptwake doctor reports what every AI tool on the machine is holding and how much of it sits inside a deletion window — no account, writes nothing, sends nothing anywhere. If the conclusion is that the record should not depend on one laptop, that is what PromptWake captures: prompt, response and the resulting diff, local by default and synced into a shared timeline on the paid tiers.