A security reviewer holds up codebase indexing for your team. Their objection is that directory and file names across the repository carry internal project and client names, and they assume those names travel to Cursor's servers as readable text. Which description of what actually leaves the machine should you take into that review?

Hardcursorsearchindexingprivacy

Last reviewed 21 Aug 2026

Paths are hashed on the client and the server keeps a lookup table mapping each hash back to the original path, so the names are recoverable by anyone holding that table.
The directory structure and filenames are uploaded in plain text so the index can be matched by name, which is exactly the exposure of client names the reviewer is describing.
Nothing leaves the machine during indexing at all, because embeddings are computed locally and kept inside the workspace, so no privacy review of the feature is warranted here.
File paths are encrypted before they are sent to Cursor's servers, so the client names in the tree do not travel as readable text and that objection falls away.Correct answer

Show answer & explanation

Correct answer: D. File paths are encrypted before they are sent to Cursor's servers, so the client names in the tree do not travel as readable text and that objection falls away.

Explanation

The principle — Indexing is neither fully local nor a plain upload of your tree. Data does go to Cursor's servers, but file paths are encrypted before being sent, and code content is never stored in plaintext — it is held in memory during indexing and then discarded. Knowing which of those two things is true is what lets a privacy review land in the right place.

Why the key is correct — The reviewer's specific worry is that internal project and client names sit in the path structure and would be readable once transmitted. Path encryption addresses exactly that: the names do not travel as readable text. Saying so does not end the review — a compliance process may still care that a request is made at all, that filenames are obfuscated rather than absent, or how team index sharing works — but it moves the conversation off a claim that is simply untrue, and stops a good search feature being blocked over it.

Why the others are wrong — Assuming a plaintext upload of names is the default expectation from ordinary search tooling, and it is the error that costs teams the feature. Claiming nothing leaves the machine is the mirror-image failure and the more expensive one, because it justifies skipping a review that the organisation actually requires; embeddings are not computed and kept locally in that sense. And describing the protection as a reversible hash-to-path table on the server keeps the reviewer's exposure fully intact while sounding technical — if such a table existed, encryption would be doing no work at all.

Remember this — In a privacy review, argue about the form data takes, not about whether data moves. The two claims worth carrying into the room are that paths are encrypted before transmission and that code content is not stored in plaintext. Both are checkable, both are narrow, and neither requires you to promise that nothing leaves the laptop.

Sources — Cursor's Search tool documentation.

Sources

Primary sourceSearch — Cursor · accessed 19 Aug 2026
“File paths are encrypted before being sent to Cursor's servers.”
Primary sourceSearch — Cursor · accessed 19 Aug 2026
“Code content is never stored in plaintext; it is held in memory during indexing, then discarded.”

Practise 10 questions on this topic

Take Cursor AI Features — Timed Test 1 (10 questions) — scored instantly, explanation for every question, no login.

Start the test

Related questions

Related questions