DEV Community

king li
king li

Posted on

Where Cursor Stores Local Chat History: A Developer’s Hands-On Breakdown

#cursor #aitools #developertools #localstorage

If you’ve dug into Cursor’s AI coding assistant, you may have wondered: where exactly are all those chat conversations saved on my local machine?
I recently went exploring to locate the raw chat database, and I’m sharing the paths, caveats, and practical developer use cases here.

Cursor is built on Electron, so it follows the standard Electron storage pattern for user data, stored in the globalStorage directory.

Local File Paths

  • Windows: 
%APPDATA%\Cursor\User\globalStorage
Enter fullscreen mode Exit fullscreen mode
  • macOS: 
~/Library/Application Support/Cursor/User/globalStorage
Enter fullscreen mode Exit fullscreen mode
  • Linux: 
~/.config/Cursor/User/globalStorage
Enter fullscreen mode Exit fullscreen mode

Inside this folder, you’ll find SQLite database files that persist your full chat sessions, prompts, code snippets, and conversation metadata.
Unlike many cloud AI tools that keep all history server-side, Cursor writes these records directly to your disk.

Important Distinction: Cursor vs Encrypted Messaging Apps

This is a critical point I want to clarify:
Desktop apps like WeChat store chat logs in heavily encrypted databases. Even if you find the database files on disk, you cannot parse or read them without the application’s internal decryption routines.

Cursor’s local SQLite storage is not locked with that same heavy encryption. For developers, that opens up interesting possibilities, but it also introduces security tradeoffs.

What You Can Do With This Local Database

  1. Backup your AI coding conversations Before migrating to a new workstation, copy the database folder to preserve all your prompt history. No cloud sync required.
  2. Build custom analysis scripts You can write simple Python scripts to query the SQLite DB and audit your prompt patterns, extract reusable code snippets, or build a personal knowledge base of past debugging sessions.
  3. Offline access You can review previous AI coding chats even when you have no internet connection.

The Fine Print & Gotchas

  • Local storage does not mean all AI inference runs locally. Unless you configure Cursor to connect to a local LLM, your prompts and code are still sent to Cursor’s remote API to generate responses. The local DB only saves the conversation after the API returns results.
  • Database schema can break on app updates. If Cursor pushes a new version, the table structure may change, and your custom parsing scripts may stop working.
  • Security risk: Since the DB is readable, anyone with access to your local disk can open it and read your prompts and code. If you work with proprietary source code, secure your workstation accordingly.

Closing Thoughts

For developers who value ownership of their AI conversation data, Cursor’s local-first chat storage is a standout feature.
It’s not perfect, but it gives us a level of transparency that most AI coding tools simply do not offer.

Have you tried querying Cursor’s SQLite database yourself? Hit me up in the comments.

Top comments (1)

Collapse
 
yong_tokenslayer profile image
Yong •

Useful pointer. A few things I ran into reading this database programmatically on macOS (my machine, so your numbers will differ):

  • The main state.vscdb can get very big. Mine is around 25 GB, with a -wal file next to it. So "copy the folder" as a backup is heavier than it sounds.
  • It's a live SQLite database in WAL mode, so copying it while Cursor is running can give you an inconsistent snapshot. Quit Cursor first, or open it read-only.
  • On the security point: the same database also holds login tokens, not just chat history. A backup copy is closer to a credential than to a text export, so I'd store it accordingly.

And +1 on the schema warning. I wouldn't depend on specific table or key names across Cursor updates.