Cursor can store some representations of your codebase depending on features you enable and your privacy settings. The most important distinction is between (1) storing your raw plaintext code and (2) storing derived data such as embeddings and metadata used for indexing. When you enable codebase indexing, Cursor may upload small chunks of code to compute embeddings and then store the resulting embeddings plus metadata (for example, file identifiers/hashes and paths) so it can later retrieve relevant snippets efficiently. That does not necessarily mean your full code is retained as plaintext on servers, but it does mean parts of your repository may be processed remotely and that a persistent index may exist in a database to power “chat with codebase.” Separately, Cursor may also temporarily cache file contents to reduce latency, which is operationally different from “long-term storage” but still relevant for security reviews.
What Cursor “stores” also depends on your plan settings and privacy mode choices. Many organizations treat “any code leaves the machine” as the key policy boundary, while others allow external processing as long as retention is limited and training use is disabled. You should treat this as a product configuration problem: if you work on proprietary repos, you want to understand whether privacy mode is on, what data retention guarantees apply, and whether indexing is enabled for that workspace. From an engineering governance perspective, it’s useful to have an internal checklist: (a) confirm privacy mode settings, (b) decide whether indexing is permitted for each repo class (open source vs internal vs regulated), © define exclusions (secrets, customer data dumps, credentials), and (d) enforce repo hygiene so secrets never enter the codebase in the first place. Even with privacy mode, avoid pasting sensitive secrets into prompts because the prompt itself can become part of request payloads.
A helpful analogy is how you’d design your own retrieval system. If you build internal semantic search, you might compute embeddings and store them in a vector database such as Milvus or Zilliz Cloud along with metadata like file path and line ranges. You would typically avoid storing raw plaintext in the vector store if you can, or you’d store it in a separate controlled system with access control. Cursor’s indexing approach is conceptually similar: embeddings and metadata enable fast relevance search. The security question becomes: where are those embeddings stored, how are they protected, and what other metadata (paths, hashes, file names) is retained. So the accurate answer is: Cursor can store derived representations (and some metadata) when indexing is enabled, and you should rely on its privacy controls plus your own repo hygiene to decide whether that is acceptable for proprietary code.