You remember the error you fixed, but not which Cursor workspace contains the conversation. That’s the search workflow in cursor-history, which I maintain.
It reads existing local history; you don’t need to have installed it when the conversation happened. On the machine holding those files, with Node.js 20.x or 22.x–26.x:
npx --yes [email protected] search "connection pool" --json
The query matches message text case-insensitively across discovered workspaces. Copy a returned sessionId into a follow-up read:
session_id='PASTE_RETURNED_SESSION_UUID'
npx --yes [email protected] show "$session_id"
Keep the same data roots and workspace filter for both commands. An exact UUID is useful here because list indices can change as new sessions appear.
The reader handles supported Composer databases, Agent transcripts, and CLI/ACP Store sessions. Those sources don’t always contain the same fields. A readable result can still be partial; a failed query doesn’t prove the conversation was deleted.
This finds and reads content. It doesn’t add a global history panel inside Cursor, fetch remote history, or make an IDE session resumable in the CLI. The project’s backup and migration operations are narrower, covering Composer databases and eligible Composer sessions.
If a session visible in Cursor doesn’t appear in the results, the OS, Cursor/CLI versions, source directory names, and the exact command would be useful details for a report. Please omit private conversation content.