The short answer
You highlighted one function and asked for a refactor. Your editor extension may also have sent the surrounding file, several open tabs, your project structure, and in some configurations recent terminal output. If any of that contained a credential, the credential went too.
This is documented behaviour, not a bug. It is how these tools produce relevant suggestions. But almost nobody reads the context-collection settings, and the defaults are tuned for output quality rather than for the fact that you work under an NDA.
Why extensions send more than your prompt
A model with no context produces generic code. To suggest something that fits your codebase, the assistant needs to see the codebase — your naming conventions, your types, the function you are about to call.
So extensions gather context automatically. Common sources, roughly in order of how widely they are collected:
- The current file, usually in full rather than just your selection.
- Open editor tabs, on the reasonable theory that what you have open is relevant.
- Neighbouring and recently edited files in the same project.
- Project structure — directory layout, dependency manifests.
- Symbol and type information from the language server.
- Terminal output and error text, where the tool offers to explain failures.
- Git metadata — branch names, sometimes recent diffs.
None of this is sinister. All of it is invisible at the moment you press the shortcut.
Where this turns into a leak
The .env problem. You have a .env file open in a tab from earlier. It
holds a production database URL and an API key. You ask for help with an
unrelated function. The extension includes open tabs as context.
Terminal output. A failing command printed a connection string, or a stack trace embedded a token. You click “explain this error.” The whole buffer goes.
Test fixtures with real data. Someone, at some point, pasted a real customer record into a fixture file to reproduce a bug. It has been in the repository for two years. It is now context.
Infrastructure as code. Terraform state and Kubernetes manifests are full of resource identifiers, internal hostnames and occasionally secrets that should have been in a vault.
The pattern in all four: the leak comes from a file you were not thinking about, which is exactly why configuration beats vigilance here.
What to configure
1. Path exclusions. Most serious tools support a file that lists paths never to be used as context — check your tool’s documentation for the exact filename and syntax, since it differs. At minimum exclude:
.env
.env.*
**/secrets/**
**/*.pem
**/*.key
**/credentials*
**/terraform.tfstate*
**/*.kubeconfigThen verify the exclusion took effect rather than assuming, because a misplaced pattern file silently does nothing.
2. Turn off terminal and shell integration unless you actively need it. It is usually a separate toggle from code context and it is the highest-risk source relative to how often it is useful.
3. Reduce context scope where the setting exists. Some tools let you limit context to the open file rather than the workspace. You lose some suggestion quality. On client work that is the right trade.
4. Close what you are not using. The lowest-tech control available: your
open tabs are an attack surface, and closing the .env tab costs nothing.
5. Use a secrets manager so credentials are never in files at all. This is the real fix. Everything above is compensating for secrets being in the filesystem in the first place.
Verifying rather than trusting
Do not take a vendor’s word on what leaves your machine. Two ways to check:
Look for an audit or request log. Better tools expose what was sent. Read it once after a few normal edits, and you will learn more about your setup than any documentation gives you.
Watch the traffic. With a local proxy you can inspect the payloads directly. This is straightforward for anyone comfortable with network tooling, and it answers the question definitively for your configuration rather than in general.
One caution: check your tool’s terms before doing this. Some vendors treat inspecting or intercepting their client traffic as a terms violation, even on your own machine and your own data.
If you manage a team
Set the exclusion patterns centrally and commit them to the repository, so a new developer inherits them rather than being told about them. Then document which tools are approved, on which tier, with which settings — one page.
The failure mode is not a developer doing something reckless. It is fifteen developers each accepting fifteen sets of defaults, and nobody being able to answer an auditor asking where the code went.