2 min lesson
What indexing actually stores (the privacy answer)
Describe the practical point in "And semantic indexing handled it the same way it handles a small new project", then say what it changes.
Step 1 of 2
What indexing actually stores (the privacy answer)
Be precise about the mechanic, because it doubles as the most-cited security reassurance. On first open Cursor chunks the repo into functions/pieces and generates vector embeddings; the embeddings are hashed and stored, but the raw code is held only ephemerally and then deleted - the long-term store is just the vector DB. At prompt time, semantic search pulls the most relevant chunks into context. A .cursorignore file specifies files Cursor should never index or view, the control surface for sensitive code.
Other tools lean on grep (substring search), which is slow and degrades on a large, deep codebase. Because Cursor indexes the whole repo into a vector DB, it understands what you semantically mean and stays fast. Even an ambiguous prompt like "change the button to blue" returns an applicable result. This is what lets cloud agents work in very large repos: one demo ran against Grafana - a repo roughly ten years old, ~70K stars, 13K-plus contributors and potentially gigabytes of files - and semantic indexing handled it the same way it handles a small new project. The point to carry is that the scaling story is about semantic indexing, not a memorized file count.
"It didn't see my other file" almost never means the model is broken. It means that file wasn't retrieved into context. The fix is usually mechanical: open the file, @-mention it or write a rule that points the agent at it. Note that @-mentioning guarantees a file lands in context rather than relying on semantic search to surface it - and you can @-mention a past chat too, which summarizes it and reads the transcript so you inherit the summary without carrying all prior context forward. Teaching developers to reason in terms of 'what's in context right now' turns a frustrating mystery into a debuggable system.
Learn more
Full explanation
The codebase, not the chat, is the source of truth
When a long session fills the window, the real context the next agent needs isn't the chat back-and-forth - it's the codebase, the commits, the new code and the docs the previous agent left. So the handoff move is to ask the agent to "summarize what you've done up to this point," copy that small text into a fresh agent and continue. You can also fork a chat (hover a message, fork from there) to branch with only part of the prior context - you can't selectively delete context, only fork. For long runs Cursor auto-detects a near-full window, compacts the key learnings and initializes a new agent to resume the same task.