If I add .env to .gitignore, can the agent still leak it to teammates?

Yes. The .gitignore file tells git not to track a path; it does nothing to an AI agent at runtime. The agent reads files in the working directory through its file tools and can quote the value into a different file, a chat message, or a test fixture that is itself tracked. Per Cursor's documentation, terminal and MCP server tools bypass .cursorignore. Block reads at the agent's permission layer, not at git.

Does Cursor or Claude Code privacy mode stop .env leaking to other developers?

Privacy mode controls whether the provider stores or trains on your transcripts. It does not stop the agent from reading the file, writing it into another file, or committing it. Teammates see what is in the repo and in the shared workspace regardless of your provider setting. Treat privacy mode as a vendor-side control over telemetry, not a team-side control over secret propagation.

How can a teammate replay my agent transcript and find a secret I never shared?

Most team plans share transcript history within the workspace. If your agent quoted a secret in a chat session, a teammate with workspace access can search history and find the value. Cursor team workspaces, Claude team plans, and GitHub Copilot Business retain conversation logs scoped to the workspace, not the individual developer, which is the propagation path most teams forget about.

What is the safest deny rule for Claude Code's settings file?

In ~/.claude/settings.json, add a permissions block with deny entries for Read(./.env), Read(./.env.*), Read(./**/.env), and any vault path. This forces the agent to ask before opening, and a stricter policy can add Bash(cat:./.env*) too. Ship this config as a .claude/settings.json in the repo so every contributor inherits the same rules instead of relying on each developer to set them.

If my mobile app's .env leaks into the compiled bundle, does App Review catch it?

App Review does not audit secrets in source. The automated layer in App Store Connect does scan binary strings for token-shaped patterns, and Google Play's pre-launch checks do similar work. Neither is exhaustive. Per OWASP MASVS-STORAGE-1, the responsibility for keeping secrets out of the bundle stays with the developer. A pre-submission scan of the compiled IPA, APK, or AAB closes the visibility gap.

Can AI agents leak my .env to other developers?

For a solo developer, the worry about an AI agent reading .env stays local: the file goes to the model, the model talks back, and any damage lives inside one machine. For teams sharing a workspace, the leak surface widens, because the agent's outputs land in places other developers already look: branches, transcripts, Model Context Protocol configs, and screenshots pasted into tickets.

Short answer

Yes. An AI coding agent can leak your .env to other developers when it pulls the file into its context and then surfaces that content on a shared surface: a committed test file, a team chat transcript, a hardcoded MCP server config, or a screenshot pasted into Slack or Linear. Per Cursor's ignore files documentation, the terminal and MCP server tools used by Agent bypass .cursorignore entirely, so an indexing exclusion is not an access control.

What you should know

Agents read .env by design. Cursor, Claude Code, and Codex traverse the working directory to ground answers in real files, which includes any .env they encounter.
.gitignore does not block agents. Source control ignores are not consulted by the agent at read time.
Indexing exclusion is not access exclusion. .cursorignore blocks semantic search and @-mentions; the agent's terminal, file read, and MCP tools still see the file.
MCP config files routinely carry secrets. GitGuardian's State of Secrets Sprawl review counted thousands of unique credentials in MCP configuration files on public GitHub alone.
AI-assisted commits leak twice as often. Industry analysis cited around AI-assisted commits puts the secrets leak rate near 3.2%, against a baseline near 1.6% for human-only commits, roughly double the rate.

How does an AI agent actually get hold of .env in the first place?

The shortest path is the working directory. When you open a project in Cursor, Claude Code, or a Codex CLI, the agent traverses files as it answers prompts. Per the Cursor ignore files documentation, Cursor's default index ignore list includes .env*, but that protection applies only to semantic search and codebase mention. The agent's terminal, file read, and MCP tools remain free to open the file.

The second path is the dotenv loader. Modern coding agents that run npm or pip commands inherit the same dotenv package production code uses, which means the agent process picks up every variable on the developer's machine for the duration of the shell. Knostic documented one such case where Claude Code automatically read .env, .env.local, and similar environment variable files and silently loaded API keys into agent memory; the agent later included one of those keys in a test file pushed to a branch.

The third path is the agent's helpful suggestion: a prompt asking for a quick .env.example often copies the real values across rather than placeholders, and then asks for permission to save the file under a tracked path.

Where does that .env content actually travel after the agent has read it?

Reading the file is the first step; whether it becomes a leak depends on where the agent writes the value next. Five surfaces matter on a team:

Inline in a test file or example. The agent quotes the live key in a fixture, then opens a pull request.
A committed MCP server config. claude_desktop_config.json or .cursor/mcp.json carrying hardcoded tokens lands in the repo.
Cloud-stored chat transcripts. Cursor, Claude, and Copilot retain conversation history under the user's account; teammates with shared workspace access can replay it.
Screenshots pasted into Slack, Linear, or Jira. The transcript becomes searchable in another tool with looser access control.
Telemetry from a compromised MCP server. Public reporting of supply-chain attacks against AI IDEs in 2025 and 2026 has described npm packages that install rogue MCP servers and quietly exfiltrate environment data from inside Cursor, Claude Code, and Windsurf.

In team plans, the danger compounds. A teammate troubleshooting your build can search the shared agent log for SUPABASE_SERVICE_ROLE_KEY and find the value your agent quoted last Tuesday.

Can a teammate using the same AI subscription see what my agent saw?

Not through the model itself, but through every place the model wrote the value down.

The clearest case is the committed branch. An agent that helpfully adds SUPABASE_SERVICE_ROLE_KEY=eyJ... to a lib/test-utils.ts and pushes it puts the secret in the team's normal review path. The reviewer sees the file and either flags it, ignores it, or merges it. Once merged, every developer with repo access has the value. Public reporting in 2025 counted around 29 million leaked secrets across GitHub repositories, with the rate of AI-assisted commits noticeably higher than the human baseline.

The subtler case is shared MCP. If your team standardised on a shared MCP server (an internal Jira bridge, a Snowflake adapter, a Supabase admin tool), the credentials in its config sit on every machine that pulls the repo. Per GitGuardian's review, more than two thousand valid credentials lived in MCP configs on public GitHub alone; the private-repo number is presumed to be higher.

The third case is transcript inheritance. When a teammate copies your starter prompt or pastes your agent transcript into theirs to reproduce a result, the .env-derived values travel along with the rest of the context.

Leak vector	Crosses team boundary by	Visible to teammates without action	Mitigated by `.gitignore`	Mitigated by `.cursorignore`
Test file committed by agent	Git push	Yes	No, the file is not in ignore	Only if `.env` itself was never read
Hardcoded MCP server config	Git push	Yes	If the config is ignored, yes	No, MCP tools bypass it
Shared chat transcript	Cloud workspace	Yes, by transcript replay	No	No
Screenshot in Slack or Linear	Manual paste	Yes	No	No
`.env.example` filled with real values	Git push	Yes	No, example is tracked	Partial
Rogue MCP server exfiltration	DNS / HTTPS	No, but attacker-visible	No	No

The table reads in one direction. Source control ignores and indexing ignores were never the right perimeter for a runtime secret.

Does .cursorignore or .gitignore stop the leak between developers?

Only partly, and the gap is what most teams miss. Per the Cursor ignore files documentation, .cursorignore blocks "Semantic search," "Code accessible by Tab, Agent, and Inline Edit," and "@ mention references," but the same page says plainly that the terminal and MCP server tools used by Agent cannot block access to code governed by .cursorignore. .cursorindexingignore is narrower again: files listed there remain accessible to AI features and only drop out of codebase searches.

.gitignore blocks the file from being committed. It does nothing to the agent reading the file, and nothing to the agent writing the value into a different, tracked file.

For Claude Code, the closest control is the permissions block in ~/.claude/settings.json with a deny entry on Read(./.env) and Read(./.env.*). This is opt-in and silent if forgotten, which is why a shared .claude/settings.json checked into the repo (so every contributor inherits the deny list) is the practical pattern teams converge on.

What does this mean for shipping a mobile app from a shared repo?

For a mobile team submitting to App Store Connect or Google Play, the .env risk arrives twice. Once, in the obvious way, when a leaked Supabase service role or Stripe secret turns into a billing or data event. And once at the binary level, when an agent that imported a server-only key into app/config/index.ts makes it inlined into the IPA or AAB at build time, where any reverse engineer with apktool can read it.

Per the OWASP MASVS, MASVS-STORAGE-1 requires that no sensitive credential be stored unprotected inside the app bundle, and MASVS-CRYPTO-2 reinforces the same point for keys used in cryptographic operations. App Review does not scan source code; it scans the binary, and string searches inside compiled binaries are the first thing static analysis pipelines perform.

For builders who want a sanity check on the compiled artefact rather than the editor view, PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission scanning aligned with OWASP MASVS, including searches for known secret patterns inside APK, AAB, and IPA files. The agent's view is the source tree; the scan looks at what shipped.

What to watch out for

The first myth to drop is that adding .env to .gitignore ends the conversation. The agent reads the file regardless and can re-emit the value into a file that is tracked. The control belongs at the agent's permission layer or at a runtime secret injection layer, not at git.

The second is that AI subscriptions labelled "team workspace" provide isolation across developers. In practice the workspace makes replay easier, because any chat the agent saw can be opened by any teammate with workspace access. Treat shared workspaces the same way you would treat a shared Slack channel for secrets.

The third is that MCP servers are passive plumbing. Public supply-chain reporting in 2025 and 2026 has shown rogue MCP packages quietly siphoning environment variables and tokens out of Cursor, Claude Code, and Windsurf. Treat every new MCP entry in claude_desktop_config.json the way you would treat a new npm dependency: with provenance checks, pinned versions, and a review step.

Key takeaways

An AI agent leaking .env to other developers is rarely a model breach; it is the agent quoting the value into a file, transcript, MCP config, or screenshot that teammates already see.
.cursorignore blocks indexing; the agent's terminal and MCP tools still read whatever they want, so treat indexing and access as two separate controls.
For Claude Code, an explicit deny Read(./.env*) rule in ~/.claude/settings.json is the closest thing to a hard stop, and it should live in the repo as .claude/settings.json so every contributor inherits it.
For a mobile build, the secondary risk is the same key being inlined into the bundle at build time; for a compiled-artifact audit aligned with OWASP MASVS, PTKD.com (https://ptkd.com) runs pre-submission scans of the APK, AAB, or IPA.
Treat every shared MCP server config as a credential file, not a config file; the GitGuardian numbers put the difference between the two in the thousands of valid keys.