2 min lesson
What indexing actually stores, the privacy-ticket answer
Walk through each part of "What indexing actually stores, the privacy-ticket answer", then explain what each one does.
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 and pieces and generates vector embeddings. Code is encrypted during indexing and the embeddings are stored with obfuscated filenames.
- Raw code is ephemeral
- The actual source is held only briefly while the index builds, then discarded. 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, that blocks the listed files from Cursor's code context and @-references. Terminal and MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. tools are separate and are not governed by it.
- .cursorindexingignore
- The index-only lever: it excludes files from indexing while they stay reachable directly. An ignore rule only guarantees a path was never indexed if it existed before the first index.
"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.
Semantic retrieval finds code that isn't named the way you'd guess, because the embedding index matches on meaning. Grep covers the exact strings, and the agent harness uses both.
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.
The real levers: .cursorindexingignore to exclude paths from indexing, .cursorignore to keep files out of context, 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, so don't conflate them.