2 min lesson
What indexing actually stores (the privacy-ticket answer)
Use "What indexing actually stores (the privacy-ticket answer)" to explain each part and the role it plays.
Step 1 of 2
What indexing actually stores (the privacy-ticket answer)
A large share of enterprise tickets are really "what happens to our code?" in disguise. Knowing the exact storage mechanic lets you answer with precision instead of hand-waving, which is what earns trust with a security-conscious admin.
- Chunk + embed
- On first open Cursor chunks the repo into functions/pieces and generates vector embeddings. The embeddings are hashed and stored.
- Raw code is ephemeral
- The actual source is held only ephemerally during indexing, then deleted. The only long-term store is the vector database, not your code.
- Retrieval at prompt time
- Semantic search over those embeddings pulls the most relevant chunks into context when the user prompts.
- .cursorignore
- A file (distinct from .gitignore) naming paths Cursor must never index or view: the control surface for keeping sensitive code out of indexing and agent reach.
"We don't keep your codebase long-term: embeddings live in a vector DB, the raw code is deleted after indexing." That sentence resolves most privacy tickets.
Tools that rely on grep (substring search) stall on a large repo: on a 2M-line codebase, substring search is slow and degrades. Because Cursor indexes the whole repo into a vector DB, it matches what the user semantically means and stays fast, demoed on Grafana at ~2M+ lines and 30,000 files.
This is why "it can't find anything in our huge monorepo" is usually an indexing-not-built problem, not a model problem. A fully-built index is what makes large-repo retrieval work at all.
Learn more
Full explanation
Scoping a large codebase: ignore vs team rule
When a team asks how to point Cursor at a smaller subset of a giant C++ tree, reframe first: thousands of source files isn't large by Cursor's standards, since it indexes very large monorepos performantly. Fundamentally you're just opening a folder, so it's about what you populate in it.
Two real levers: .cursorignore to exclude paths from indexing, or a team rule to steer the agent toward a subset. Cursor's own pattern is pulling their website out into a sub-repository people can iterate on for docs. Note that indexing scope and access scope are separate axes - don't conflate them.