Windows Terminal does not check new PATH variables

[Tydoki]

Windows Terminal version

1.11.3471.9

Windows build number

10.0.22000.0

Other Software

tested with ffmpeg and yt-dlp

Steps to reproduce

1. Add any folder to your path variable with an exe in it
2. Open Windows Terminal
3. Run that exe from within windows terminal (powershell or cmd)

Expected Behavior

exe runs

Actual Behavior

The term 'X' is not recognized as a name of a cmdlet... etc

With windows terminal set as default I can simply click "powershell 7", in my start menu" and it opens within windows terminal. And for some reason that first tab works. This issue only occurs when I open Windows Terminal by clicking "Windows Terminal" or using any tab that isn't the first tab when opening it by clicking "powershell 7" .

These commands also work on powershell 7 or cmd when not used in Windows Terminal.

To get any new exe to work I have to either add the exe to a folder already in my PATH or add new folder as usual and then reinstall windows terminal for it to be recognized.

Note: Brand New PC (literally got today), Windows 11, Windows Terminal came preinstalled.

Sorry if this is just a me issue.

[zadjii-msft]

Wait so this isn't #1125 after all. That's weird. It's a known bug that the Terminal won't reload env vars while it's running, but that should only apply when you:

1. Open the terminal
2. add something to the PATH
3. open another tab

Starting the terminal from cold (no existing windows / tabs) should reload the env vars, and they shouldn't change while the Terminal is running.

Maybe this has to do with the way the Terminal is invoked via defterm, when you launch pwsh directly and it opens magically in the Terminal. Hmm.

[Tydoki]

Yeah from cold start it didn't work.

I've been installing things since this is a new pc and somewhere along the line tho is started to work...

But yeah it was like that for the 3 hours I was trying to fix it.

[zadjii-msft]

and somewhere along the line tho is started to work

Weird. Well at least it's working now? Maybe it's possible that the defterm COM server was still hanging around to service new defterm requests, so it wasn't as cold a launch as it might have seemed. Hard to know for sure. Glad the issue went away at least!

[TommyCox]

I also am having this issue on a new installation after installing GitHub CLI with winget.

Windows Terminal Version: 1.12.10334.0
Windows Build: 10.0.22543.1000

I tried restarting and killing Windows Terminal from Task Manager a few times to no effect.
Old terminals can find the executable, but not Windows Terminal.

[zadjii-msft]

@TommyCox what's the PATH when running the Terminal, vs running cmd.exe directly?

Does the PATH in Terminal change depending on if it's launched from the Run Dialog (Win+R) vs the Start Menu? (#11777 is the one I'm thinking of)

[TommyCox]

@zadjii-msft Yes, that seems to be the case.

I didn't check the PATH directly, but powershell (Windows Terminal) was able to find executables on the updated path after relaunching from a taskbar icon instead of wt.exe. This also seems to update the path for future wt.exe launches as well.

[cforce]

zadjii-msft @TommyCox
Why is this closed - I have the same issue
I can start a new cmd from windows start menu and my user PATH is loaded
If i do the same ( same cmd and params) via terminal it doesn't reflect the PATH changes.
I can open a dozens new terminal windows cmd windows from the same running terminal parent instance - issue still remains.
It seems toi recover when i completly terminate the terminal parent and create a new and a new cmd window . so its terminal app caching the context. Do you use some cached state of context?
How to enforce REAL (re)loadind onf env?
My workaround is now to use choco's "refreshenv" .. but5 hey this is defintetly a bug in the terminal application so please reopen this issue.

[zadjii-msft]

This was closed because OP's issue ultimately resolved itself. The issue you're describing is tracked in #1125

[Ares9323]

relaunching from a taskbar icon instead of wt.exe. This also seems to update the path for future wt.exe launches as well.

I can confirm that launching from wt.exe doesn't load the new environmental variables, launching it from the taskbar icon or the start menu icon works fine, but in my case the PATH is not updated if I open the wt.exe again

[ktzsolt]

I also struggled with this issue, I had set up env var for User and Machine scope but it was only visible with echo $env:PATH when I launched a powershell window directly but not from a PS tab launched from windows terminal.

I even closed and reopened the whole windows terminal with no luck, but then I opened up task manager and saw that when I close the windows terminal it is not yet closed but it stays alive for as long as 30 seconds as a process with one Runtime Broker subprocess and when you reopen windows terminal you open up again that previous process that still doesn't have the new environment variables.

So the solution is to close windows terminal and wait 30-60 seconds before you open it op (or kill the process from task manager).

[mithom]

this issue still exists... restarted terminal multiple times, PATH doesn't update, opening a regular cmd or powershell does show the new path.

[lhecker]

The fix (#14999) is only available in Windows Terminal Preview 1.18. Are you sure you're using that version?