Use fresh environment block on new terminals in Windows

[eslachance]

At the moment, if any environment variables change, or new "apps" are installed while VS Code is running, in order for those changes to be recognized VS Code needs to be closed and re-open.

For instance, when running npm i -g <something> or choco install <package> in another prompt or powershell window, those new commands are not recognized until the app is rebooted.

It would be great if adding a new terminal instance with + would load these new variables/apps/notsurewhatterminologytouse.

[MirzaSikander]

Worse yet, if you have multiple instances of vscode running, all of them need to be killed and restarted for the environment variables to be updated for the sake of one window where you needed it.

[MirzaSikander]

Actually it is stuck in a weird state. Two instances have different values for the same variable. One is updated while the other is not. Not sure how to reproduce it. I think it is somehow tied to different workspaces. It would be great if somebody could shine a light on how vscode powershell integrated terminal fetches the environment variable.

[MirzaSikander]

Okay so I think I found two different issues.

• You do need to kill all instances to refresh environment variables. This is easy to repro.

1. Start 2 vscode instances pointing to different directories.
2. Add a new env variable through System Properties > Environement variables called TEST
3. Check $env:TEST in both instances. Result: Not updated.
4. Restart one instance by killing it and then using Open folder to open the directory. Check again. Result: Not updated.
5. Restart both instances by killing both and using Open folder. Check again. Result: Updated.

• The second issue is that if you open your workspaces using links under Recent, you will find that even after restarting VSCode, the environment variables are not updated.

1. Start one instance.
2. Update env variable.
3. Kill instance.
4. Open VScode by right clicking on Task bar and selecting the folder from Recent Workspaces
5. Check env variable. Result: Not updated.

[Tyriar]

npm i -g <something>

@eslachance are you on Windows? Isn't the global node_modules bin directory added to PATH, I would have expected this to work?

[eslachance]

I believe what I added was a global module such as eslint or it might have been windows-built-tools which of course does more than just copy javascript to the node modules. However, this does not simply affect node. This affects any and all things that you can do that adds something to the path, or does anything to modify what's accessible from the console. So even though my request stems from using npm i -g, the actual issue is broader and the feature request would definitely enhance the user experience for a lot of people (in my humble opinions).

[claudeleveille]

Git also seems to be affected by this. Specifically, the ssh-agent included in Git for Windows. This program relies on environment variables to work, so when VS Code is started before the ssh-agent program, VS Code's Git integration can never find out about the ssh-agent process and make use of the SSH keys stored in there. VS Code as a whole should periodically refresh it's environment variables to fix all of the issues mentioned here, and possibly also as a response to certain events. A rejected Git push/pull based on a failed publickey authentication attempt comes to mind as a good idea for the first event.

[jonfelske]

One thing that worked for me ( on mac ) was to add the environment variables to the bash profile. That way whenever you restart vscode or open a new terminal instance anything in the profile is loaded.

jonfelske$ vi ~/.bash_profile
# Environment variable needed
export YOUR_ENV_VAR_NAME="some value here"

You can then either restart the terminal or use "source ~/.bash_profile" and the environment variable will be picked up. Hope that helps! :)

[claudeleveille]

What I ended up doing is installing PuTTY and running setx.exe GIT_SSH "C:\Program Files\PuTTY\plink.exe". Then I could load my keys into pagent and never had any other problems (except for not being able to accept host key fingerprints with Git). To trust host keys: echo 'y' | plink.exe <hostname-or-ip> does the trick in a script (though that's not super secure, I know).

If only we could just converge on a single SSH suite inside of Windows, whether that's the WSL one, or the native port. I think that even PowerShell has some SSH functionality built-into sessions now.

[nishant-labs]

I have same issue on mac for .bash_profile changes to take effect, Either will have to restart whole vscode IDE or execute "source ~/.bash_profile".

Apart from that I have issue with duplicated paths in PATH variable. Below code is in .bash_profile:-

MAVEN_HOME=/Users/<user>/apache-maven-3.5.2 TEST=/Users/<user>/test_1_0 PATH=$PATH:$MAVEN_HOME/bin:$TEST

When I echo in mac terminal I get <other paths>:/Users/<user>/apache-maven-3.5.2/bin:/Users/<user>/test_1_0

where as vscode integrated terminal outputs as <other paths>:/Users/<user>/apache-maven-3.5.2/bin:/Users/<user>/test_1_0:/Users/<user>/apache-maven-3.5.2/bin:/Users/<user>/test_1_0

Can you please resolve this.

[ps2goat]

Thanks, @MirzaSikander! I couldn't figure out why the environment variable was hanging around. I was always re-opening the project via the recent options (either via taskbar or within vs code's start page).

Opening the folder by using the 'open folder' option did indeed load the new environment variable values! This is important when switching your AWS_PROFILE, which is needed for IAM authentication to create a token for kubernetes.

[Tanja-4732]

Is there any plan as of right now to add this functionality?

[IAmHopp]

Thanks, @MirzaSikander! I couldn't figure out why the environment variable was hanging around. I was always re-opening the project via the recent options (either via taskbar or within vs code's start page).

Same here, it's been bugging me for a while as I exclusively open via the taskbar. Nicely spotted, @MirzaSikander. This issue is more critical imo, as it's hard to even zero in on what's happening and it doesn't seem like it's by design, as opposed to having to close/reopen.

[edwin-hendriks]

I am a teacher on the Radboud University in the Netherlands and my students have a lot of problems with this issue. Most work on Windows 10 and for them the easiest work around is to restart their computers. Because this is counter intuitive, it often takes them a while to figure out how to solve it. So fixing this issue would be a great help to me and my students.

[Tyriar]

This could probably be fixed by https://github.com/Microsoft/vscode/issues/70248#issuecomment-472582012

I'll take a note on that calling out this specific issue.

[woutervugt]

Can the in my opinion super weird behavior of caching environment variables but only when working with recent projects be disabled somehow? I have exactly 0 understanding of the need for doing this, but hey, lets say it is useful for 'some scenarios'.

Being able to not have this super annoying behavior would be quite beneficial!

[eslachance]

@woutervugt this isn't about caching and it's not a Vscode specific issue. The same thing happens if you have a command prompt or bash open, and change your environment variables - you have to close and reopen the prompt to see those changes. However, in the world of Vscode, all the terminals need to be restarted, which means all of the vscode instances, and that's why a solution has to be provided by the team to reload them without a full restart.

So to be clear: the vscode team didn't cause this issue, it's inherent to all terminals, but we would welcome a solution from them with arms wide open.

[woutervugt]

Thanks for your reply. I understand env vars are loaded at the Windows process level. One thing that I am then really not understanding is how this keeps on happening even when I do close all windows. That is exactly the first thing that I do! (haven't checked process explorer). Of course hitting the cross to close a bunch of windows does not necessarily mean the process terminates. Is there anything in that area that you can think of that might cause a process to stay around for a bit in a headless fashion? Also, how does terminating processes interact with recent projects? Would not expect there to be a relation between those.

Gonna test a bit and see what is happening!

[woutervugt]

Ok, this is just crazy I have an environment variable with current value in VSCode being 'Ralph' (testing deployment for him,anyhoo) So, while VSCode remains open with 1 window, I update the env var via the System properties of Windows. Changing the value from 'Ralph' to 'Ralph1' Then, close VSCode open vscode via Taskbar --> Recent Projects open the POSH integrated terminal, and see what value it has.

And it was not Ralph, nor Ralph1 (but Wouter, which it was somewhere before I did deployments for eh Ralph).

So, now VSCode has a env var value that is not equal to what it was before I refreshed the process / window, and is also not equal to the actual value in Windows.

Must be me but this is just really unexpected behavior. It seems that somewhere the env vars are persisted. Might be the POSH plugin, which truth be told has its fair share of weirdness)

[woutervugt]

Made a screen recording file. If you want I can drop that somewhere.

Must be a dev if you find it funny that I actually have a screen recording tool I didn't know and then see that it creates MHT files. Want me to send the MHT file :) I swear it won't cause harm!! lol

[IAmHopp]

This issue is more critical imo, as it's hard to even zero in on what's happening and it doesn't seem like it's by design, as opposed to having to close/reopen.

Just reiterating here, as I think these last comments are added evidence, that the issue with opening via the taskbar should be prioritized over the need to close/reopen all terminal instances.

Regardless of one's thoughts in regards to closing/reopening, at least it makes some sort of sense. Projects opened via the taskbar not picking up new values is just confusing.

I probably wouldn't have figured that one out to this day if it wasn't for @MirzaSikander.

[SamB]

I personally would be pretty happy with something like code --restart that would:

1. Close the existing instance of vscode, but remember what windows were open
2. Start a new instance
3. Open those windows again

Failing that, it'd be nice to have code --quit or something like that, which would ask the existing instance to close, taking care to follow the principle of least surprise with respect to sequences such as the following:

code --quit
code .

That is, such sequences should first wait for the existing instance to quit, then fire up a new one. Note, however, that I'm not certain which of the above commands should actually do the waiting; the main point is that we really don't want to open a window or editor in the instance that just started quitting.

[Tyriar]

Related: https://github.com/Microsoft/vscode/issues/70248

[jonscheiding]

I encountered the second issue and was totally baffled till I found this issue.

The second issue is that if you open your workspaces using links under Recent, you will find that even after restarting VSCode, the environment variables are not updated.

I opened that as a separate issue since this one seems to be conflating it with a more straightforward feature request.

[Tyriar]

I just made inheriting the environment configurable for Linux/macOS as part of https://github.com/microsoft/vscode/issues/70248, let's track the feature for Windows here.

[IAmHopp]

Nice one @jonscheiding. Still think that issue is more crucial due to its unpredictability. Hope it gets some traction.

[eslachance]

As a side-note (since I opened this feature request in the first place): if you think it's not possible to modify env variables without restarting the entire app, please explain how CMDER does it (https://github.com/cmderdev/cmder). And also suggest a reasoning on why VSCode couldn't just do the same. (edit: that sounded super condescending and angry - IT WASN'T MEANT TO! I was just preventively answering anyone that thought it wasn't possible!)

[Tyriar]

It's completely possible

[Driky]

Since this is still open here is a trick to reload the path in powershell (integrated or not):

$env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User")

[x-raay]

What worked for me was exiting and then relaunching the cmd/git bash to fetch the latest env vars and then run

code . 

so the process starts with these new env vars

[eslachance]

What worked for me was exiting and then relaunching the cmd/git bash to fetch the latest env vars and then run

code . 

so the process starts with these new env vars

Having to shut down and relaunch the editor is exactly what we don't want to have to do, and the reason this feature request exists. I feel like you didn't read, or misunderstood, this entire thread...