You hardcoded an API key while building fast in Cursor, and now, before submitting, you are wondering whether that key is sitting on Cursor's servers. The short version is that your code does pass through Cursor's cloud to power its AI features, but what gets stored is limited, and the part that should worry you most is somewhere else entirely.
Short answer
Your code is sent to Cursor's servers and model providers to power indexing, completions, and chat, so a hardcoded key can transit the cloud. With codebase indexing, Cursor discards the plaintext after computing embeddings and keeps only embeddings and obfuscated metadata. Cursor's Privacy Mode adds zero-data-retention terms with its model providers, so code data is not stored by them or used for training, and it is enabled by default for team members. The larger exposure is that a hardcoded key also ships inside your app bundle.
What you should know
- Code transits the cloud for AI features: indexing, completions, and chat send code to Cursor and its model providers.
- Indexing stores embeddings, not plaintext: Cursor discards the source after computing the embedding and keeps embeddings plus obfuscated metadata.
- Privacy Mode means zero data retention: with it on, code is not stored or trained on, and it is enabled by default for teams.
- .gitignore and .cursorignore are skipped by default: a key in a gitignored .env is not indexed, but a key hardcoded inline in a source file is.
- The real exposure is the binary: a hardcoded key ships in your compiled app, where anyone can extract it.
Does your code actually leave your machine in Cursor?
Yes, for the features that need a model. Completions, chat, and codebase indexing all send code to Cursor's servers and the underlying model providers, because the work happens in the cloud and not on your laptop. For indexing specifically, Cursor uploads your files in chunks to compute embeddings and then discards the plaintext, storing only the embeddings and obfuscated metadata such as hashed file names in a vector database. The original source stays on your machine and is not retained as plaintext. So your code is processed in the cloud, but the persistent copy Cursor keeps is the embedding, not your raw file.
What does Privacy Mode change?
Privacy Mode adds a no-retention guarantee on top of that flow. Cursor's security page describes Privacy Mode as technical controls and contractual zero-data-retention terms with its model providers, so that code data is not stored by those providers or used for training. It is available on free and Pro accounts and is enabled by default for members of a team. With Privacy Mode off, the same AI features still work, but you lose the contractual assurance that nothing is retained. For anyone anxious about secrets, turning Privacy Mode on is the first setting to check.
Are your hardcoded keys included, or excluded?
It depends on where the key lives. Cursor skips files listed in .gitignore and .cursorignore by default, so an API key kept in a gitignored .env file is not indexed or sent. A key hardcoded directly inside a source file is treated like any other code and is included in indexing and AI requests unless you exclude that file. The table sorts the common cases.
| Where the key lives | Sent to Cursor's cloud for AI features? |
|---|---|
| In a .env file that is gitignored | No, excluded by default |
| In a path listed in .cursorignore | Excluded from indexing, best effort from chat |
| Hardcoded inline in a source file | Yes, unless you exclude that file |
| The resulting embeddings, not raw code | Stored; the plaintext is discarded after the request |
One caveat: .cursorignore is best effort for chat requests, so a recently viewed file you listed there can still be included in an AI request. The reliable rule is to keep secrets out of source files entirely, rather than to rely on an ignore list to hide them after the fact.
What is the bigger risk than Cursor's cloud?
The key shipping inside your app. Cursor's retention is bounded by Privacy Mode and plaintext discard, but a key hardcoded in your code does not stay in the editor: it gets compiled into your app bundle and shipped to every user. Anyone who downloads the app can extract strings from the binary and read it, which is the exposure that actually drains a budget or leaks a database. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA for hardcoded secrets against OWASP MASVS, which is the layer where this key becomes a real problem. For the related question of whether App Review itself reads keys in your binary, see does App Review check API keys.
What to watch out for
If a key was ever hardcoded, treat it as exposed and rotate it. Once a secret has been committed to a repo, sent through an AI tool, or compiled into a build, you cannot reliably un-expose it, so the safe move is to revoke and reissue it, then store the new one server-side or in environment configuration. Do not lean on .cursorignore as a security control, because it is a best-effort filter for AI context and not a vault. The habit that prevents all of this is simple: never put a live secret in client code, route the call through your own backend, and let the client hold only short-lived tokens.
What to take away
- Cursor sends code to its servers for AI features, so a hardcoded key can transit the cloud, but indexing stores only embeddings and Privacy Mode adds zero data retention.
- Keep secrets in a gitignored .env or out of the client entirely, because a key hardcoded inline in a source file is indexed unless you exclude it.
- The bigger exposure is the binary: a hardcoded key ships to every user, so rotate any key that was ever hardcoded.
- Confirm the binary is clean with a pre-submission scan such as PTKD.com, which reads the APK, AAB, or IPA for hardcoded secrets against OWASP MASVS before you submit.
