Prevent Copilot read .env* file

[nhatchimai111]

Select Topic Area

Question

Copilot Feature Area

Copilot Agent Mode

Body

Configure Visual Studio Code to prevent Copilot from accessing and suggesting content from .env files.

Specifically:

• Create or update the .gitignore file to exclude .env files
• Add .env patterns to .copilot-ignore file
• Configure VSCode settings.json to explicitly exclude .env files from Copilot suggestions
• Verify Copilot's access settings for sensitive files

Please provide the current structure of your .env files and VSCode workspace configuration for more targeted guidance.

For reference, consult:

• GitHub Copilot documentation on file exclusions
• VSCode documentation on workspace settings
• Best practices for handling environment variables

I have update many configs on VSCode and my project. However Copilot still read .env files in my project

[MohammadKurjieh]

@nhatchimai111 check this discussion thread https://github.com/orgs/community/discussions/13334

[Anorak001]

Hi @nhatchimai111,

You're on the right track with trying to exclude .env files from Copilot suggestions. However, Copilot does not currently guarantee exclusion of specific files unless explicitly configured. Here's a quick checklist to ensure all necessary configurations are in place:

Steps to Prevent Copilot from Accessing .env Files

1. Add to .copilot-ignore

Ensure your project has a .copilot-ignore file at the root with the following entry:

.env
.env.\*

Note: Copilot uses .copilot-ignore similar to .gitignore, but for suggestion control.

2. Update VS Code settings.json

In your workspace or global settings:

"copilot.exclude": [
  "**/.env",
  "**/.env.*"
]

This tells Copilot to avoid reading or suggesting content from these files.

3. Confirm .gitignore (optional but recommended)

While this doesn't impact Copilot directly, make sure .env is ignored by Git:

.env
.env.*

4. Restart VS Code

After applying changes, restart your VS Code instance to ensure all exclusions take effect.

---

If you've done all of the above and Copilot is still accessing .env content, it's worth reporting directly via the [GitHub Copilot feedback form](https://github.com/github/copilot/issues) or using the in-editor feedback tool.

Let me know if you'd like help reviewing your current .copilot-ignore and settings files.

[MohammadKurjieh]

@Anorak001 can you please share a link to the docs.
I can't find .copilot-ignore referenced anywhere

Thanks

[Anorak001]

Here are the relevant documentation links:

• Content exclusion generally available — GitHub Changelog

Copilot does not support .copilot-ignore in individual or free plans. The only official way to prevent it from accessing .env files is through the Content Exclusion feature, available exclusively to Copilot Business or Enterprise users. Once you (or an org admin) configure exclusions—e.g.:

"*":
  - "**/.env"
  - "**/.env.*"

in Settings → Copilot → Content exclusion, Copilot will no longer provide completions within those files or use their contents to influence suggestions elsewhere.

[haplorhine]

These suggestions were likely generated by Copilot. I also got the same hallucinations when asking copilot about excluding files. There is no documented mechanism that allows excluding files via .copilot-ignore or copilot.exclude.

[qhaas]

These suggestions were likely generated by Copilot. I also got the same hallucinations when asking copilot about excluding files.

The hallucination is valuable. I am now using this as an example for my colleagues as to why we need to fact check GenAI InfoSec configurations carefully.

[tyler36]

"copilot.exclude": [
"/.env",
"/.env.*"
]

I get an "Unknown configuration setting" warning. Also tried: github.copilot.exclude key.

VSCode: 1.104.1
GitHub Copilot extension: 1.372.0

[ashmeet07]

🔒 Preventing Copilot from Reading .env Files

The reason your local configurations (.gitignore, settings.json) are not reliably preventing Copilot from accessing .env files is because GitHub Copilot's file exclusion feature is primarily managed server-side, and requires a paid tier.

1. The Official Solution (Requires Paid Subscription)

The only fully supported and guaranteed way to exclude files from Copilot's context is using the Content Exclusion feature, which is available only to users with Copilot Business or Copilot Enterprise subscriptions.

If your organization has the correct subscription, an administrator must set the exclusion rules at the organization level:

• Go to: GitHub Organization Settings → Copilot → Content exclusion.
• Set the rule: The exclusion rule must be defined using the appropriate syntax for the files you want to ignore.

Example Exclusion Rule:

"*":
  - "**/.env"
  - "**/.env.*"

2. The Local Workarounds (Less Reliable)

While the paid feature is the official solution, you can attempt to use these local configurations as a secondary measure:

File	Configuration	Status/Note
.copilot-ignore	Place this file in your project root: .env .env.*	This file is intended for suggestions control, but its effectiveness can be limited, and it may not be supported on all Copilot tiers.
settings.json	Use the copilot.exclude setting: "copilot.exclude": ["**/.env", "**/.env.*"]	This setting is often reported by users as generating an "Unknown configuration setting" warning and may not be officially supported by the current Copilot extension version.

Conclusion

If Copilot is ignoring your local settings and your primary goal is to prevent the exposure of sensitive environment variables, you must either:

1. Upgrade your Copilot subscription to Business/Enterprise and use the official Content Exclusion feature.
2. Move sensitive variables into a secure vault or secrets manager (like Azure Key Vault, AWS Secrets Manager, or GitHub Secrets) instead of keeping them in unencrypted .env files that must live in your project structure.

[haplorhine]

That ist mostly hallucinated. There are no known mechanisms like .copilot-ignore or copilot.exclude to exclude files and their content nor a possibility to prevent copilot from reading the input and output of open terminals.

[ashmeet07]

---

1. Content Exclusion (Excluding Files) 🚫

The claim that there are "no known mechanisms like .copilot-ignore or copilot.exclude to exclude files" is incorrect.

Claim Detail	Current Reality (Official GitHub Documentation)
No exclusion mechanisms exist.	False. GitHub Copilot Business and Enterprise plans support an official Content Exclusion feature.
No .copilot-ignore file.	True. There is no official file named .copilot-ignore or copilot.exclude that you drop into a repository to manage exclusions.
How Exclusion Works	Exclusion is configured by administrators in the repository or organization settings on GitHub.com. They specify file paths and patterns to ignore.
Effect of Exclusion	Excluded content is not used to inform code suggestions in any file, and code completion is disabled within the excluded files themselves.

---

2. Terminal Input and Output Access 🛡️

The claim that there is "nor a possibility to prevent Copilot from reading the input and output of open terminals" is an oversimplification.

Claim Detail	Current Reality (How Copilot Interacts with Terminals)
Copilot reads all terminal data.	Misleading. Copilot's terminal interaction is primarily through the Copilot Agent and Copilot Chat. It runs commands it initiates and reads the resulting output for context (e.g., test failures, build errors).
Inability to "Prevent" Reading	While you can't install a setting to block all terminal input/output globally, its access is generally limited to the context it needs for a specific chat or agent task. For example, the Copilot Agent is often instructed to only read specific files or selections for context.
Practical Challenges	Ironically, users often report that the Copilot Agent is unreliable at consistently capturing the output of long-running or complex commands, which sometimes requires developers to use workarounds (like piping output to a file) for the agent to correctly read the results.

[levinosaber]

trash, 转人工

[rodriguezrrp]

I am having this issue too. I used to add

"files.associations": {
    ".env*": "dotenv"
},
"github.copilot.enable": {
    "dotenv": false
}

in my settings.json file, as recommended by this Jan 2024 StackOverflow Q&A, but it seems that is no longer supported? I noticed the Copilot icon does NOT have a slash through it on the bottom taskbar like it did a year ago. I am using the free version of Copilot, but -- assuming I interpreted "Copilot is now generally available for all Copilot Business and Copilot Enterprise users" (see 2024-11-12 github blog and github docs accessed on 2025-11-08) correctly -- it makes no sense Github would be excluding this important privacy feature to paying users only.

Is there a known, documented, and please NOT AI-generated recommendation to solve this issue??

[K1taSun]

hello,

Your .env file is likely still open in a VSCode tab. You must close the file.

Copilot reads your open tabs for context, regardless of your settings. The settings only prevent it from accessing closed files in your workspace.

How to Fix It

Close the .env file tab. This is the most important step.

Open your Workspace settings.json (Press Ctrl+Shift+P and find "Preferences: Open Workspace Settings (JSON)").

Add this setting to block Copilot from accessing these files when they are closed:
JSON

{
"copilot.exclude": {
"/.env": true,
"/.env*": true
}
}

Reload VSCode: Press Ctrl+Shift+P and run "Developer: Reload Window".

[ash-iiiiish]

Root Cause: Local settings (.gitignore, .copilot-ignore, settings.json) are ineffective for preventing Copilot from accessing .env file content. Copilot reads all open tabs for context regardless of these exclusions.

Official Solution: Content Exclusion feature requires Copilot Business or Enterprise subscription. Configured server-side on GitHub.com under Organization or Repository Settings using:

"*":

• "**/.env"
• "**/.env.*"

Effect takes up to 30 minutes after configuration.

Immediate Workarounds (No Subscription Upgrade):

  Never leave .env files open in VS Code tabs
  
  Use external secrets manager (Azure Key Vault, AWS Secrets Manager, GitHub Secrets)
  
  Create separate workspace for sensitive files with Copilot disabled
  
  Manually disable Copilot when working with sensitive configurations

Key Point: Language-based disabling prevents completions within .env files but does not stop Copilot from using their content as context elsewhere.

[qhaas]

If you want GitHub Copilot to stop reading or suggesting content from your .env files, here’s what usually works:

1. .gitignore
   Make sure your .env files are ignored so they don’t accidentally get committed:

.env
.env.*

Looks like it ignores files / patterns listed in .gitignore as long as the file is not open in vscode:

What sources are used for context?
Workspace context searches through the same sources a developer would use when navigating a codebase in VS Code:

All indexable files in the workspace (workspace index), except those ignored by a .gitignore file
...
.gitignore is bypassed if you have a file open or have text selected within an ignored file.

2. .copilot-ignore
   At the root of your project, create a .copilot-ignore file and add:

*.env
.env.*

I cannot find references in the documentation to .copilotignore or .copilot-ignore, but the .copilotignore exists in the code. This implies it is an undocumented feature, so relying on it would be poor infosec practice if we cannot find it documented.

3. VSCode settings
   In your settings.json (workspace or user), add:

{
  "github.copilot.files.exclude": [
    "**/.env",
    "**/.env.*"
  ]
}

I'm seeing references in the docs to files.exclude being used as an exclusion list, but not github.copilot.files.exclude.

[Gecko51]

Quick summary of what actually works vs what doesn't, since there's a lot of conflicting info in this thread:

What genuinely prevents Copilot from using .env content:

1. Keep the file closed. Copilot reads open tabs for context regardless of any settings. If the .env tab is closed, it can't read it. This is the simplest fix.

2. .gitignore. The workspace index skips gitignored files unless they're currently open. So adding .env* to .gitignore + keeping the file closed = not used as context.

3. Content Exclusion (Business/Enterprise only). Configured in org/repo settings on GitHub.com. This is the only server-side guarantee. For individual users it's not available.

What doesn't work (even though you'll see it recommended a lot):

• .copilot-ignore file: undocumented, no official support
• copilot.exclude in settings.json: throws "Unknown configuration setting", not a real option
• github.copilot.files.exclude in settings.json: also not officially supported

Partial fix:
"github.copilot.enable": { "dotenv": false } stops completions within .env files but doesn't prevent those files from being used as context when you're editing other files.

Bottom line for free/individual users: close your .env tabs and add .env* to .gitignore. That's as good as it gets without a Business/Enterprise plan.

[haplorhine]

Closing files doesn't prevent copilot from reading them. Would be very laborious to open all files, that should be read or changed by copilot. Copilot can read all files in the workspace.

It reads .env files and can show the content, but it doesn't automatically edit them (There is a confirmation prompt for editing .env files)

Adding .env to gitignore doesn't prevent copilot from reading it when closed.