Terminal env vars (WT_SESSION, etc) aren't set when set as the Default Terminal

[StartAutomating]

Windows Terminal version

1.12.10983.0

Windows build number

10.0.22000.0

Other Software

No response

Steps to reproduce

Change settings to launch terminal instead of command shell.
Close instances of terminal
Run powershell/pwsh
Check $env:WT_PROFILE_ID
See that it is blank

Expected Behavior

$ENV:WT_PROFILE_ID should never be blank, because having a blank profile ID disables changing settings for that profile.

Actual Behavior

$ENV:WT_PROFILE_ID is not set when terminal is launched with pwsh/powershell, after changing system settings.

[zadjii-msft]

Notes:

• Terminal: add support for Window Manipulation (CSI t, resize), or reject it explicitly (and force a client resize) #5094 (comment)
• Feature Request: Clients of terminal need a way to inquire about the capabilities of the terminal #1040

That summarizes the issue at hand, and a proposed solution. We think this'll require some additional OS side changes (but it would be great if it didn't)

[chausner]

The same seems to apply to environment variables defined in settings.json. I guess this is by design.

[tig]

+1 on this.

Do this:

• Start.Run "pwsh"
• Type $env:WT_SESSION

This breaks console apps (e.g. those built with Terminal.Gui) that are trying to determine if they are running in WT by checking for WT_SESSION.

This bug also applies when running console apps in the VS 2022 debugger because WT_SESSION is not set there either.

[BDisp]

The better way to check what terminal default is set is read Windows registry, see https://support.microsoft.com/en-us/windows/command-prompt-and-windows-powershell-for-windows-11-6453ce98-da91-476f-8651-5c14d5777c20.

[tig]

The better way to check what terminal default is set is read Windows registry, see https://support.microsoft.com/en-us/windows/command-prompt-and-windows-powershell-for-windows-11-6453ce98-da91-476f-8651-5c14d5777c20.

No, checking the registry only helps determine the default terminal. This does not help code determine what terminal it is running in. The WT team needs to fix this bug that's causing WT_SESSION to not be set.

[BDisp]

No, checking the registry only helps determine the default terminal. This does not help code determine what terminal it is running in. The WT team needs to fix this bug that's causing WT_SESSION to not be set.

I have one doubt here. And if you have ope your application with cmd and you also have conhost and Windows Terminal opened, how the WT_SESSION will inform you that you are running your application on cmd or Windows Terminal? If Windows Terminal is opened and running another different app, I think the WT_SESSION will be also available but does not meaning that it's running your application. If I'm wrong I beg sorry for that.

[BDisp]

Sorry about my confusion. Run Win+R->pwsh.exe $env:WT_SESSION return empty, but run Win+R->C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.18.2822.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe return a GUID.
I see that both commands open the same executable files C:\Program Files\PowerShell\7\pwsh.exe and C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.18.2822.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe for the current user.
Thus I think the GUID should return on both commands and some fix must be done. Thanks.