starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Windows Terminal does not check new PATH variables #16455

New Issue
Closed
opened 2026-01-31 05:12:44 +00:00 by claunia · 12 comments
claunia commented 2026-01-31 05:12:44 +00:00
Owner
Copy Link

Originally created by @Tydoki on GitHub (Jan 22, 2022).

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.

Originally created by @Tydoki on GitHub (Jan 22, 2022). ### 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.
claunia commented 2026-01-31 05:12:45 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 24, 2022):

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.

@zadjii-msft commented on GitHub (Jan 24, 2022): 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.
claunia commented 2026-01-31 05:12:45 +00:00
Author
Owner
Copy Link

@Tydoki commented on GitHub (Jan 25, 2022):

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.

@Tydoki commented on GitHub (Jan 25, 2022): 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.
claunia commented 2026-01-31 05:12:46 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 25, 2022):

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!

@zadjii-msft commented on GitHub (Jan 25, 2022): > 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!
claunia commented 2026-01-31 05:12:46 +00:00
Author
Owner
Copy Link

@TommyCox commented on GitHub (Feb 7, 2022):

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.

image

@TommyCox commented on GitHub (Feb 7, 2022): 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. ![image](https://user-images.githubusercontent.com/55894704/152821390-d0284c53-6dbc-4573-b7ba-b840969ca289.png)
claunia commented 2026-01-31 05:12:47 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 7, 2022):

@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)

@zadjii-msft commented on GitHub (Feb 7, 2022): @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)
claunia commented 2026-01-31 05:12:48 +00:00
Author
Owner
Copy Link

@TommyCox commented on GitHub (Feb 8, 2022):

@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.

@TommyCox commented on GitHub (Feb 8, 2022): @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.
claunia commented 2026-01-31 05:12:48 +00:00
Author
Owner
Copy Link

@cforce commented on GitHub (Dec 9, 2022):

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.

@cforce commented on GitHub (Dec 9, 2022): [zadjii-msft](https://github.com/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.
claunia commented 2026-01-31 05:12:49 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 9, 2022):

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

@zadjii-msft commented on GitHub (Dec 9, 2022): This was closed because OP's issue ultimately resolved itself. The issue you're describing is tracked in #1125
claunia commented 2026-01-31 05:12:49 +00:00
Author
Owner
Copy Link

@Ares9323 commented on GitHub (Jan 16, 2023):

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

@Ares9323 commented on GitHub (Jan 16, 2023): > 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
claunia commented 2026-01-31 05:12:49 +00:00
Author
Owner
Copy Link

@ktzsolt commented on GitHub (Mar 31, 2023):

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).

@ktzsolt commented on GitHub (Mar 31, 2023): 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).
claunia commented 2026-01-31 05:12:49 +00:00
Author
Owner
Copy Link

@mithom commented on GitHub (Jun 27, 2023):

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

@mithom commented on GitHub (Jun 27, 2023): this issue still exists... restarted terminal multiple times, PATH doesn't update, opening a regular cmd or powershell does show the new path.
claunia commented 2026-01-31 05:12:50 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 27, 2023):

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

@lhecker commented on GitHub (Jun 27, 2023): The fix (#14999) is only available in Windows Terminal Preview 1.18. Are you sure you're using that version?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Needs-Attention Needs-Tag-Fix Needs-Triage Product-Terminal Resolution-No-Repro
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#16455
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?