Shell Integration restores outdated ENV vars via VSCODE_ENV_REPLACE even after .env is updated or removed

🐛 Bug Report: Shell Integration restores outdated ENV vars via `VSCODE_ENV_REPLACE` even after `.env` is updated or removed

Issue Summary

VS Code's shell integration appears to persist environment variables across terminal sessions using VSCODE_ENV_REPLACE, even if those variables were originally set via a .env file that has since been deleted or modified.

This leads to terminal environment pollution, where outdated or incorrect environment variables appear in the integrated terminal without any current code, config, or .env file referencing them.

Steps to Reproduce

Create a VS Code workspace with a .env file containing:
```
DATABASE_MONGO_HOST=my-mongo-host.com
```
Open a terminal → this gets injected via VSCODE_ENV_REPLACE
Modify .env to:
```
DATABASE_MONGO_HOST=localhost
```
or delete the .env file
Restart VS Code and open a new terminal
The old value (my-mongo-host.com) is still present in the terminal environment

Expected Behavior

Old VSCODE_ENV_REPLACE variables should not persist forever
There should be a way to clear or view per-workspace shell environment cache
Updated .env files should replace previously exported values, not conflict with them

Actual Behavior

Terminal session contains outdated values from previous sessions
These variables are not visible or configurable through any UI
This persists even across .env changes or project reloads

Workaround

Manually delete the affected workspace’s workspaceStorage folder

~/Library/Application\ Support/Code/User/workspaceStorage/<workspace-id>/

This clears state.vscdb where VSCODE_ENV_REPLACE is tracked

VS Code Version

Version: 1.99.0 (Stable)
OS: macOS
Shell: Bash via /bin/bash --init-file .../shellIntegration-bash.sh

Suggested Fix

Provide a command like: Terminal: Clear Workspace Environment Variables
List VSCODE_ENV_REPLACE values in the “Configure Environment Variable Collections” panel
Auto-clear outdated vars when .env is modified or deleted

Related Code

The script at:

/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/contrib/terminal/common/scripts/shellIntegration-bash.sh

Contains the logic re-injecting old variables via VSCODE_ENV_REPLACE.

Thanks for your help — this would really improve DX for devs using .env files!

Please fix this.. this was driving me crazy trying to work out what was going on!

Please fix this.. this was driving me crazy trying to work out what was going on!

No kidding, i could not for the life of me figure out why my database connections were failing to authenticate. I had to use 2 different External AIs to help me figure what exactly was causing it.

also a temporary workaround I found and use that seems to work most of the time is:

dotenv.config({override: true});

Are folks able to repro this on older version of VS Code?
My guess is this would have to do something with how often and how we are loading env var from .env files.

in relation to envVarCollection

Unbelievably, the issue seems to be caused by the official VSCode Python extension:

By default, the Python extension looks for and loads a file named .env in the current workspace folder, then applies those definitions. The file is identified by the default entry "python.envFile": "${workspaceFolder}/.env" in your user settings

https://code.visualstudio.com/docs/python/environments#_environment-variable-definitions-file

The fix is either to a) disable the Python extension for the workspace, or altogether, or b) to set python.envFile to an empty string.

VSCode team, you need to talk to your colleagues about how absolutely irresponsible it is for a language plug-in to decide to automatically load non-language specific configuration files. And it especially should not be the default.

So many hours wasted debugging to finally find out about this issue 😢

Here is the link to the downstream issue on vscode-python. I did not verify yet that this is actually the root cause for this specific issue, but I did check that I had the same envVars.txt with an old copy of environment variables which correspond to the one set in my env.

Alberto Santini (@albertosantini)

Alberto Santini (@albertosantini) Thank you for your answer. Disable the pyhton extension and restart vscode. Caching of environment variables is solved. However, if the python extension is enabled, there will still be a cache of environment variables next time.

Franco Nogarin (@spydmobile)

Franco Nogarin (@spydmobile) Did you also have Python extension activated when you reproduced this issue?

Also those with Python extension activated, does same problem persist if you opt out of Python env experiment by adding:

  "python.experiments.optOutFrom": [
    "pythonTerminalEnvVarActivation"
  ],

into your settings.json?

Make sure to run Python Clear Cache and Reload after adding the setting.

Silently overriding environment variables defined in and loaded from a .env file is very questionable.

Anthony Kim (@anthonykim1)

@spydmobile Did you also have Python extension activated when you reproduced this issue?

Also those with Python extension activated, does same problem persist if you opt out of Python env experiment by adding:
  "python.experiments.optOutFrom": [
    "pythonTerminalEnvVarActivation"
  ],
into your settings.json?

Make sure to run Python Clear Cache and Reload after adding the setting.

yes Anthony Kim (@anthonykim1) I did, thanks.

I just wasted 3 hours because of this... 😡 I thought I was losing my mind!

I'm affected and also wasted probably 5+ hours because of this. When's this going to get fixed?

Please diagnose the root cause of the issue by running the command F1 > Help: Troubleshoot Issue and following the instructions. Once you have done that, please update the issue with the results.

Happy Coding!

Let me know if people experience different behavior, and please watch out if you experience anything strange as we are getting rid of pythonTerminalEnvVarActivation experiment around Wednesday of this week.

It seems like pythonTerminalEnvVarActivation may have been affecting .env variable caching as well.
Feel free to directly ping me or file issue on Python extension if this behavior or some other behavior arise after later of this week. (I would say testing the behavior on Thursday and onward should be good as pythonTerminalEnvVarActivation would be gone by then)

After disabling all MS python-related extensions, restarting VS Code, and then re-enabling, I no longer see this pythonTerminalEnvVarActivation experiment available in my settings.

While I'm not yet sure what my workflows around setting environment variables for my python projects will be going forward, I agree setting the environment variables should be explicitly controlled, and not have multiple ways to source the environment variables in different ways that could potentially clash. For example, in launch configurations, we can set the .env file explicitly:

{
            "name": "Python: Module",
            "type": "python",
            "request": "launch",
            "module": "controller",
            "console": "integratedTerminal",
            "env": {
                     "ENV": "dev"
                   }
            "envFile": "${workspaceFolder}/.envs/.env",
}

I'm just not sure what is the best way to ensure my terminal sessions for my python projects automatically source my .env file (if I choose to configure my terminals that way). The Python extension currently has a straightforward way to configure whether we want our terminal sessions to auto-activate our python virtual environment, so I would like it to be something like that. Similarly, the newer Python Environments extension has commands to start a terminal with our virtual environment sourced. I would like to see such settings for choosing the .env file to source as well.

That said, it should be recognized that python .env files (and python "dotenv" files for that matter) differ in syntax from command files that are truly "sourced" into a shell session like bash. In this context, I think users will still want some way for their python environment files to be interpreted and then injected into their terminal sessions.

Or, I could be totally wrong and stuck in my ways, spoiled by the "experiment" of having my python environment variables set in my shell for me. After more thought, I suppose it may be better to make my python code conditionally call load_dotenv() if it detects it is running in a development environment (presumably set in some environment variable, using the terminal.integrated.env settings in VS Code perhaps). Normally, in production, environment variables would be set by whatever container the application is running in, outside of the application code. This aspect is essentially what I would like VS Code to help me simulate during development.

Without the pythonTerminalEnvVarActivation experiment, what will be the purpose of the python.envFile setting going forward?

bitadmiral

bitadmiral I'd refer you to microsoft/vscode-python#25294

Couldnt repro and we are seeing loss of feature to even see contents from .env file

I'd refer to microsoft/vscode-python#25294

If you were to verify:

Have some contents in .env file
Have Python extension activated
Check in your terminal if you get those env vars in your terminal
(currently loss of feature) You wont see those variables at all in the terminal

Couldnt repro and we are seeing loss of feature to even see contents from .env file

I'd refer to microsoft/vscode-python#25294

If you were to verify:
1. Have some contents in .env file

2. Have Python extension activated

3. Check in your terminal if you get those env vars in your terminal

4. (currently loss of feature) You wont see those variables at all in the terminal

Can confirm, I'm having this same issue. This is breaking my Django workflow. The terminal used to automatically load the variables from .env, but now nothing loads at all from the .env file.

Removing from the milestone as this was closed as not planned.

Navigation Menu

Repository navigation

Shell Integration restores outdated ENV vars via `VSCODE_ENV_REPLACE` even after `.env` is updated or removed #246222

🐛 Bug Report: Shell Integration restores outdated ENV vars via `VSCODE_ENV_REPLACE` even after `.env` is updated or removed

Issue Summary

Steps to Reproduce

Expected Behavior

Actual Behavior

Workaround

VS Code Version

Suggested Fix

Related Code

18 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Shell Integration restores outdated ENV vars via VSCODE_ENV_REPLACE even after .env is updated or removed #246222

Description

🐛 Bug Report: Shell Integration restores outdated ENV vars via VSCODE_ENV_REPLACE even after .env is updated or removed

Issue Summary

Steps to Reproduce

Expected Behavior

Actual Behavior

Workaround

VS Code Version

Suggested Fix

Related Code

Activity

peterwake commented on Apr 15, 2025

spydmobile commented on Apr 15, 2025

spydmobile commented on Apr 15, 2025

anthonykim1 commented on Apr 17, 2025

jelling commented on Apr 30, 2025

7PH commented on May 12, 2025

MinuteReversal commented on May 12, 2025

anthonykim1 commented on May 14, 2025

Guthman commented on May 18, 2025

spydmobile commented on May 19, 2025

seidnerj commented on May 22, 2025

eriksendc commented on Jun 3, 2025

18 remaining items

vs-code-engineering commented on Jul 17, 2025

anthonykim1 commented on Jul 21, 2025

bitadmiral commented on Jul 21, 2025

bitadmiral commented on Jul 21, 2025

anthonykim1 commented on Jul 31, 2025

anthonykim1 commented on Jul 31, 2025

gavinmb commented on Aug 1, 2025

alexr00 commented on Aug 5, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Shell Integration restores outdated ENV vars via `VSCODE_ENV_REPLACE` even after `.env` is updated or removed #246222

🐛 Bug Report: Shell Integration restores outdated ENV vars via `VSCODE_ENV_REPLACE` even after `.env` is updated or removed