Is Privacy Mode in Cursor on by default for free and pro accounts?

No. Privacy Mode is off by default on Free and Pro plans, and Cursor may store prompts, code snippets, and telemetry to improve features and train models on accounts where it is off. Business and Enterprise plans have Privacy Mode forcibly enabled by the admin. If you want zero data retention as an individual user, you have to turn it on manually in Settings, under General, Privacy.

If Privacy Mode is on, can OpenAI still see my .env contents in a prompt?

Yes for the duration of the inference call, and for up to 30 days afterward under the OpenAI trust and safety hold. Zero Data Retention prevents long-term storage and training, not in-flight exposure or the abuse-review window. Treat any secret that hits the model context as effectively disclosed and rotate it if production credentials were involved.

Does .cursorignore stop the Cursor agent from reading .env?

It stops the indexing layer and chat from including the file as context, which is the main exposure path. It does not stop the agent in Agent mode from running a shell command like cat .env and ingesting the output that way. Belt-and-suspenders means keeping production secrets out of the working tree entirely, not just relying on .cursorignore as a single line of defense.

What is the difference between Privacy Mode and Ghost Mode in Cursor?

Privacy Mode tells model providers not to retain or train on your prompts, but the prompts still leave your machine and travel to OpenAI, Anthropic, Google, or xAI. Ghost Mode keeps chat history and codebase data local, with zero data retention by Cursor itself and minimal traffic outbound. Ghost Mode is the right setting when you are working with regulated data and cannot risk any cloud round trip.

Are my Cursor chats searchable after I close the project?

Chat history persists locally inside your Cursor application data, scoped per workspace, and is available through the chat history sidebar. If Privacy Mode is off, prompts may also be retained server-side by Cursor for product improvement. Clearing local history removes the sidebar entries but does not retroactively delete anything already sent to Cursor or a model provider during a non-private session.

Does Cursor AI save my .env variables in prompt history?

You are halfway through a refactor in Cursor and the question lands: the AI keeps suggesting code that references STRIPE_SECRET_KEY and SUPABASE_SERVICE_ROLE_KEY, which means it has seen your .env. Where does that file actually go after you press Enter, and is a copy of your live production credentials sitting in someone's prompt log right now?

Short answer

Cursor (the company) does not permanently store your prompts when Privacy Mode is enabled, and it routes requests under Zero Data Retention agreements with OpenAI, Anthropic, Google, and xAI, per Cursor's privacy documentation. The model providers can still retain prompts up to 30 days for abuse review, and Cursor's own indexing layer keeps embeddings and metadata even with Privacy Mode on. Your .env is read into chat and agent context by default, unless you add it to .cursorignore.

What you should know

Privacy Mode is off by default on Free and Pro plans. You have to enable it manually in Settings, General, Privacy.
Zero Data Retention applies to model providers, not to Cursor's index. Embeddings and metadata of your codebase still get stored when you index a project.
OpenAI and Anthropic keep prompts up to 30 days for trust and safety review even under ZDR contracts.
.env files are read on demand by the chat and the agent when they touch related code, unless excluded by .cursorignore.
Ghost Mode is the strictest setting: chat history, prompts, and code never leave your local machine.

Does Cursor read my .env file when I chat with the model?

Yes, in most default setups. The short answer is that Cursor builds context for every chat and completion request by pulling in files relevant to your prompt: the currently open buffer, files you @-mention, and files the AI determines are useful based on its retrieval over your indexed codebase. When you ask the chat to scaffold a Stripe checkout flow, the AI looks for environment variable names in scope and reaches for .env to ground its suggestions.

The behavior was documented by API Stronghold's analysis of how AI coding tools handle environment files: the moment your .env is referenced as context, the file's contents (including any production secret you have not bothered to move to a vault yet) get serialized into the prompt and shipped to the model provider's API. This is not a Cursor-specific behavior. GitHub Copilot, Claude Code, and Windsurf operate on the same pattern.

The practical implication is that any developer who works on a project where the .env is committed alongside the code, or kept in the project root with real values, is at risk of pushing those values into a remote inference call several times per day. Nobody has to misuse the keys for this to count as an exposure: under most secret rotation policies, any value that left your boundary in plaintext is considered burned.

What does Cursor mean by Zero Data Retention?

Zero Data Retention (ZDR) is a contractual term between Cursor and the model providers it forwards your requests to. According to Cursor's data use page, enabling Privacy Mode causes Cursor to send your prompts with a ZDR flag to OpenAI, Anthropic, Google, and xAI, instructing those providers not to log the prompt for longer than the duration of the inference call, and not to use the prompt for training.

A few details get glossed over in the marketing copy. ZDR is not the same as the prompt never existing outside your laptop. The prompt is still:

Composed locally in Cursor with your .env content (or whatever context the AI selected) inline.
Encrypted in transit to Cursor's backend.
Forwarded to a model provider with the ZDR header set.
Held in the provider's inference infrastructure for the duration of the request, and (per OpenAI and Anthropic's published terms) up to 30 days for abuse and trust and safety review.
Deleted after that window.

The second important nuance: ZDR covers the model provider's side, not Cursor's. Even with Privacy Mode on, Cursor's index layer holds embeddings of your code, file metadata, and short-lived caches to make subsequent chats faster, as the company's trust center documentation makes clear. Plaintext code is not retained for training, but the embedding space still encodes recognizable structure from your repository, including environment variable names.

Where exactly do my prompts go, depending on the setting?

It helps to lay this out in one table. Cursor has three privacy postures, and the data each one retains is different.

Setting	Prompts stored by Cursor	Prompts stored by model provider	Indexing data on Cursor	`.env` read into context
Privacy Mode off (Free, Pro default)	Yes, used for product and model improvement	Yes, retained per provider's standard policy	Yes, embeddings and metadata	Yes, unless `.cursorignore`
Privacy Mode on (Business default)	No long-term storage by Cursor	No long-term storage, up to 30 days for abuse review	Yes, embeddings and metadata	Yes, unless `.cursorignore`
Ghost Mode	No, chat stays on device	Not applicable, no cloud round trip for chat history	Local only	Local read only

The column that surprises people is the second one. ZDR is a contract that says the provider deletes after use, but the OpenAI enterprise privacy documentation explicitly notes that API inputs may be retained up to 30 days for trust and safety, even under zero retention agreements, unless the customer has signed a custom amendment. Anthropic's commercial terms describe a similar window. So a STRIPE_SECRET_KEY that shipped in a prompt last night is technically reachable through legal process, an insider misuse event, or an incident at the provider for roughly a month.

How do I stop Cursor from reading .env in the first place?

The cleanest defense is a .cursorignore file at the project root with .env* patterns excluded. The format mirrors .gitignore. A reasonable baseline looks like:

.env
.env.*
.env.local
.env.production
secrets/
*.pem
*.key
config/credentials.yml

This stops the chat and the indexing layer from including the file as context, which covers the most common exposure path. The limit, as the Keyway writeup on AI coding agent secrets lays out clearly, is that Agent mode can still read any file on disk via shell tools. If the model decides to run cat .env to debug a startup error, the output of that command lands in the next agent turn just like any other tool result.

The defenses that survive Agent mode are architectural, not configuration tweaks:

Keep production secrets out of the working tree. Use a secret manager (1Password CLI, Doppler, AWS Secrets Manager, Vault) and inject values at process start through a wrapper, so the .env on disk holds only placeholders or dev-grade values.
Use separate dev and prod credentials. A leaked dev API key on a Stripe test mode account is annoying. A leaked prod key is a 3 a.m. incident. Cursor should never see prod values.
Treat any value the model has touched as rotatable. If you discover the agent read .env, rotate every credential in it and move on.

For builders shipping AI-coded mobile apps, the same care applies to anything the agent embeds into a compiled IPA or APK. Pre-submission scanning catches the common patterns. PTKD.com (https://ptkd.com) is one of the platforms that runs an OWASP MASVS-aligned static scan over compiled iOS and Android builds for credentials and storage issues, including keys that originated as .env values and got baked into the binary by a code-generating AI.

What to watch out for

A few patterns reliably surprise developers after the fact.

Privacy Mode toggled off during a long session. People turn it on when they sign up, then click around in Settings and accidentally flip it. Verify the indicator in the status bar before pasting anything sensitive.
Chat history sync between devices. If you sign in on a personal laptop and a work laptop, prompts from one machine can surface in suggestions on the other if cross-device history is on. Confirm the scope in account settings.
Custom rules files referencing secrets. Some teams put real values in cursor.rules or agent.md files thinking they are configuration. Those files are part of the prompt every turn.
Plugin and MCP servers. A custom MCP integration may forward prompts to a third party Cursor never contracted with. Audit any MCP server you install for its own data policy.
The Apply step. When the model proposes a code change that hardcodes a key from .env into a source file, accepting the diff bakes the value into source control and any downstream build. Read what you accept.

The common thread is that Privacy Mode addresses one risk (model providers training on your code) and quietly leaves several adjacent risks in place. Treating it as the whole answer is the mistake.

Key takeaways

Cursor with Privacy Mode on does not retain prompts for training and forwards them under Zero Data Retention contracts with OpenAI, Anthropic, Google, and xAI. The model providers can still hold prompts up to 30 days for abuse review.
Cursor's index layer keeps embeddings and metadata of your code regardless of Privacy Mode. Ghost Mode is the option to pick when no cloud round trip is acceptable.
.cursorignore blocks .env from chat and indexing context, but the Agent mode can still read the file with shell tools. Architectural separation of dev and prod secrets is the durable defense.
For AI-coded apps that ship to App Store or Google Play, scan the compiled IPA or APK before submission. PTKD.com (https://ptkd.com) is one of the platforms that runs a pre-submission OWASP MASVS scan focused on credentials and storage weaknesses introduced by AI coding agents.