Windows terminal path is different if launched with wt.exe #15909

@zadjii-msft commented on GitHub (Nov 17, 2021):

Sounds like you opened the Terminal before you updated the PATH? If so then this is probably #1125

@zadjii-msft commented on GitHub (Nov 17, 2021): Sounds like you opened the Terminal before you updated the PATH? If so then this is probably #1125

claunia commented

@jthoward64 commented on GitHub (Nov 17, 2021):

I have a sneaking suspicion this is related to #7204 as I have had issues with a long PATH in the past, but I think I solved that issue, and even if i were: the android sdk is not at the end of my path string

This is what running in wt.exe does to my path (and yes, my pc has been restarted many times since i updated the path):

Left is output from echo %PATH% in a normal windows terminal; right is echo %PATH% when launched from wt.exe or in quake mode (which I assume is launched via wt.exe.

@jthoward64 commented on GitHub (Nov 17, 2021): I have a sneaking suspicion this is related to #7204 as I have had issues with a long PATH in the past, but I think I solved that issue, and even if i were: the android sdk is not at the end of my path string This is what running in wt.exe does to my path (and yes, my pc has been restarted many times since i updated the path): Left is output from `echo %PATH%` in a normal windows terminal; right is `echo %PATH%` when launched from wt.exe or in quake mode (which I assume is launched via wt.exe. ![image](https://user-images.githubusercontent.com/29828269/142296629-e6c14c73-4e26-49b7-aaf0-d66f7993e097.png)

claunia commented

@elsaco commented on GitHub (Nov 18, 2021):

@tajetaje where do you add the adb dir to the path, user or system? Any location should be fine. After starting a WT session type $env:path and you should see adb in the $PATH. Looking at your above diff your adb location is missing from the $PATH. The terminal does prepends C:\Program Files\WindowsApps\Microsoft.PowerShell_7.2.0.0_x64__8wekyb3d8bbwe but is not removing any entries.

Adding adb location to system $PATH will be resolved faster since user $PATH is appended to system $PATH variable and your $PATH looks long. To see how many chars are in your $PATH measure it and count the chars:

$env:path | measure-object -character

however you're still a long way from the upper limit (is that 32,767 or more?)

@elsaco commented on GitHub (Nov 18, 2021): @tajetaje where do you add the adb dir to the path, user or system? Any location should be fine. After starting a WT session type `$env:path` and you should see adb in the $PATH. Looking at your above diff your adb location is missing from the $PATH. The terminal does prepends `C:\Program Files\WindowsApps\Microsoft.PowerShell_7.2.0.0_x64__8wekyb3d8bbwe` but is not removing any entries. Adding adb location to system $PATH will be resolved faster since user $PATH is appended to system $PATH variable and your $PATH looks long. To see how many chars are in your $PATH measure it and count the chars: `$env:path | measure-object -character` however you're still a long way from the upper limit (is that 32,767 or more?)

claunia commented

2026-01-31 04:52:00 +00:00

@jthoward64 commented on GitHub (Nov 18, 2021):

@tajetaje where do you add the adb dir to the path, user or system? Any location should be fine. After starting a WT session type $env:path and you should see adb in the $PATH. Looking at your above diff your adb location is missing from the $PATH. The terminal does prepends C:\Program Files\WindowsApps\Microsoft.PowerShell_7.2.0.0_x64__8wekyb3d8bbwe but is not removing any entries.

Adding adb location to system $PATH will be resolved faster since user $PATH is appended to system $PATH variable and your $PATH looks long. To see how many chars are in your $PATH measure it and count the chars:

$env:path | measure-object -character

however you're still a long way from the upper limit (is that 32,767 or more?)

I want to be clear: THIS IS NOT AN ISSUE WITH MY PATH
See the above image for the actual difference in my path variable. In getting those values I ended all conhost sessions and ended all windows terminal processes and then launched windows terminal normally and via wt immediately after each other. My android sdk path is in the system path and works just fine everywhere except windows terminal when launched from wt.exe (vscode, windows terminal normally, pwsh.exe, etc.)

EDIT: p.s. the max is actually around 2047 characters for the environmental variable, you are looking at the limit for a certain kind of file path (usually 270), though my path variable is still closer to 1500, should be well under the limit

@jthoward64 commented on GitHub (Nov 18, 2021): > @tajetaje where do you add the adb dir to the path, user or system? Any location should be fine. After starting a WT session type `$env:path` and you should see adb in the $PATH. Looking at your above diff your adb location is missing from the $PATH. The terminal does prepends `C:\Program Files\WindowsApps\Microsoft.PowerShell_7.2.0.0_x64__8wekyb3d8bbwe` but is not removing any entries. > > Adding adb location to system $PATH will be resolved faster since user $PATH is appended to system $PATH variable and your $PATH looks long. To see how many chars are in your $PATH measure it and count the chars: > > `$env:path | measure-object -character` > > however you're still a long way from the upper limit (is that 32,767 or more?) I want to be clear: **THIS IS NOT AN ISSUE WITH MY PATH** See the above image for the actual difference in my path variable. In getting those values I ended all conhost sessions and ended all windows terminal processes and then launched windows terminal normally and via wt immediately after each other. My android sdk path is in the system path and works just fine everywhere except windows terminal when launched from wt.exe (vscode, windows terminal normally, pwsh.exe, etc.) EDIT: p.s. the max is actually around 2047 characters for the environmental variable, you are looking at the limit for a certain kind of file path (usually 270), though my path variable is still closer to 1500, should be well under the limit

claunia commented

@jthoward64 commented on GitHub (Nov 18, 2021):

Video of the issue (Pardon the side monitor, sharex did a weird thing):
https://user-images.githubusercontent.com/29828269/142345866-4c9f8f37-28d7-4ad6-b619-c4b128c87899.mp4

@jthoward64 commented on GitHub (Nov 18, 2021): Video of the issue (Pardon the side monitor, sharex did a weird thing): https://user-images.githubusercontent.com/29828269/142345866-4c9f8f37-28d7-4ad6-b619-c4b128c87899.mp4

claunia commented

2026-01-31 04:52:00 +00:00

@thewh1teagle commented on GitHub (Nov 28, 2021):

I'm facing this weird bug too.
I updated user variables to point to cygwin64 instead of cygwin32
cmd.exe window got it.
but windows terminal no
I tried to kill all windows terminal processes and reopen but I still got the same result

@thewh1teagle commented on GitHub (Nov 28, 2021): I'm facing this weird bug too. I updated user variables to point to cygwin64 instead of cygwin32 cmd.exe window got it. but windows terminal no I tried to kill all windows terminal processes and reopen but I still got the same result ![image](https://user-images.githubusercontent.com/61390950/143724840-88bdd113-d8f9-485d-b647-8273ecfb1a3e.png)

claunia commented

2026-01-31 04:52:00 +00:00

@jthoward64 commented on GitHub (Nov 28, 2021):

I'm facing this weird bug too.

I updated user variables to point to cygwin64 instead of cygwin32

cmd.exe window got it.

but windows terminal no

I tried to kill all windows terminal processes and reopen but I still got the same result

It seems almost like wt is remembering old path variables

@jthoward64 commented on GitHub (Nov 28, 2021): > I'm facing this weird bug too. > > I updated user variables to point to cygwin64 instead of cygwin32 > > cmd.exe window got it. > > but windows terminal no > > I tried to kill all windows terminal processes and reopen but I still got the same result > > ![image](https://user-images.githubusercontent.com/61390950/143724840-88bdd113-d8f9-485d-b647-8273ecfb1a3e.png) > > It seems almost like wt is remembering old path variables

claunia commented

2026-01-31 04:52:01 +00:00

@jthoward64 commented on GitHub (Dec 10, 2021):

I will note that I have recently clean installed windows 11, so everything in this issue is about all I can give (though if need be I can mount the backup of my win 10 system I took before upgrading and salvage configs or any files if they are needed for repro)

@jthoward64 commented on GitHub (Dec 10, 2021): I will note that I have recently clean installed windows 11, so everything in this issue is about all I can give (**though if need be I can mount the backup of my win 10 system I took before upgrading and salvage configs or any files if they are needed for repro**)

claunia commented

2026-01-31 04:52:01 +00:00

@lenraven commented on GitHub (Dec 21, 2021):

I have same issue with fresh install of windows 11.

When I run the terminal with wt.exe, after I add something to the PATH, my changes are not in the environment variable.
But if I run the Windows terminal from the context menu of the Start icon, than my changes are visible.

Otherwise when I restarted the windows, then my changes are visible in wt.exe also.

@lenraven commented on GitHub (Dec 21, 2021): I have same issue with fresh install of windows 11. When I run the terminal with wt.exe, after I add something to the PATH, my changes are not in the environment variable. But if I run the Windows terminal from the context menu of the Start icon, than my changes are visible. Otherwise when I restarted the windows, then my changes are visible in wt.exe also.

claunia commented

@jthoward64 commented on GitHub (Dec 21, 2021):

I have same issue with fresh install of windows 11.

When I run the terminal with wt.exe, after I add something to the PATH, my changes are not in the environment variable.

But if I run the Windows terminal from the context menu of the Start icon, than my changes are visible.

Otherwise when I restarted the windows, then my changes are visible in wt.exe also.

This seems more like #1125

@jthoward64 commented on GitHub (Dec 21, 2021): > I have same issue with fresh install of windows 11. > > > > When I run the terminal with wt.exe, after I add something to the PATH, my changes are not in the environment variable. > > But if I run the Windows terminal from the context menu of the Start icon, than my changes are visible. > > > > Otherwise when I restarted the windows, then my changes are visible in wt.exe also. This seems more like #1125

claunia commented

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

To try and close the loop on this: This seems like a variation on many of the other env var issues we've been investigating this month. At face value, this seems unique from the others, so I'll leave it open. I'm tracking the rest in https://github.com/microsoft/terminal/issues/1125#issuecomment-1005171748. Hopefully the changes we're working on should fix this too. I'm not sure there's a good way of reproing this original issue though 😕

@zadjii-msft commented on GitHub (Jan 18, 2022): To try and close the loop on this: This seems like a variation on many of the other env var issues we've been investigating this month. At face value, this seems unique from the others, so I'll leave it open. I'm tracking the rest in https://github.com/microsoft/terminal/issues/1125#issuecomment-1005171748. Hopefully the changes we're working on should fix this too. I'm not sure there's a good way of reproing this original issue though 😕

claunia commented

@mariozski commented on GitHub (Feb 15, 2022):

I'm having the same issue with AWS SAM CLI. After installation, "sam" command is not accessible from Windows Terminal, but I can successfully run it from "Windows PowerShell" session.

@mariozski commented on GitHub (Feb 15, 2022): I'm having the same issue with AWS SAM CLI. After installation, "sam" command is not accessible from Windows Terminal, but I can successfully run it from "Windows PowerShell" session.

claunia commented

@jthoward64 commented on GitHub (Feb 15, 2022):

I'm having the same issue with AWS SAM CLI. After installation, "sam" command is not accessible from Windows Terminal, but I can successfully run it from "Windows PowerShell" session.

that is a separate issue, you are looking for #1125 I think. this issue persists between restarts and is when wt.exe sees a different PATH than windows terminal

@jthoward64 commented on GitHub (Feb 15, 2022): > I'm having the same issue with AWS SAM CLI. After installation, "sam" command is not accessible from Windows Terminal, but I can successfully run it from "Windows PowerShell" session. that is a separate issue, you are looking for #1125 I think. this issue persists between restarts and is when wt.exe sees a different PATH than windows terminal

claunia commented

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

Hey wild question - did you happen to install the Terminal from scoop, or are otherwise running the Terminal unpackaged? #12545 seems to describe a similar behavior, specifically for the scoop install, so I'm just trying to find a common thread.

@zadjii-msft commented on GitHub (Feb 22, 2022): Hey wild question - did you happen to install the Terminal from `scoop`, or are otherwise running the Terminal unpackaged? #12545 seems to describe a similar behavior, specifically for the `scoop` install, so I'm just trying to find a common thread.

claunia commented

@jthoward64 commented on GitHub (Feb 22, 2022):

Hey wild question - did you happen to install the Terminal from scoop, or are otherwise running the Terminal unpackaged? #12545 seems to describe a similar behavior, specifically for the scoop install, so I'm just trying to find a common thread.

No, iirc that install was either msstore or from GitHub's msix originally.
EDIT: though hopefully scope gives a way to repro this

@jthoward64 commented on GitHub (Feb 22, 2022): > Hey wild question - did you happen to install the Terminal from `scoop`, or are otherwise running the Terminal unpackaged? #12545 seems to describe a similar behavior, specifically for the `scoop` install, so I'm just trying to find a common thread. No, iirc that install was either msstore or from GitHub's msix originally. EDIT: though hopefully scope gives a way to repro this

claunia commented

@zadjii-msft commented on GitHub (Apr 27, 2022):

thought, not fleshed out: the "attach to current window" setting for windowingBehavior - that's gonna lose environment variables. Probably not what's at play here though.

@zadjii-msft commented on GitHub (Apr 27, 2022): thought, not fleshed out: the "attach to current window" setting for `windowingBehavior` - that's gonna lose environment variables. Probably not what's at play here though.

claunia commented