starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-24 16:05:21 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

PATH in child process includes Windows Terminal Preview installation directory, if started via Win+R wt.exe #10036

New Issue
Closed
opened 2026-01-31 02:10:54 +00:00 by claunia · 13 comments
claunia commented 2026-01-31 02:10:54 +00:00
Owner
Copy Link

Originally created by @KalleOlaviNiemitalo on GitHub (Aug 6, 2020).

Environment

Windows build number: Microsoft Windows [Version 10.0.19041.388]
Windows Terminal version (if applicable): Windows Terminal Preview 1.2.2022.0

Steps to reproduce

  1. Enable the wt.exe app execution alias of Windows Terminal Preview.
  2. Press Windows+R to open the Run dialog box.
  3. Type wt.exe and press Enter to start Windows Terminal Preview.
  4. In Windows Terminal Preview, start the Command Prompt profile.
  5. In the Command Prompt session, type PATH and press Enter.

Expected behavior

The displayed value of PATH does not include the directory where Windows Terminal Preview was installed.

Actual behavior

C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.2.2022.0_x64__8wekyb3d8bbwe is the first directory in PATH.

Notes

This is presumably caused by the Registry values that were created by AppXSvc when Windows Terminal Preview was installed:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe]
@="C:\\Program Files\\WindowsApps\\Microsoft.WindowsTerminalPreview_1.2.2022.0_x64__8wekyb3d8bbwe\\wt.exe"
"Path"="C:\\Program Files\\WindowsApps\\Microsoft.WindowsTerminalPreview_1.2.2022.0_x64__8wekyb3d8bbwe"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe]
@="C:\\Program Files\\WindowsApps\\Microsoft.WindowsTerminalPreview_1.2.2022.0_x64__8wekyb3d8bbwe\\wt.exe"
"Path"="C:\\Program Files\\WindowsApps\\Microsoft.WindowsTerminalPreview_1.2.2022.0_x64__8wekyb3d8bbwe"

According to Application Registration, ShellExecuteEx prepends the data of the "Path" Registry value to the PATH environment variable of the new process. That seems unnecessary here, as selecting Windows Terminal Preview from the Start menu does not add to PATH.

Because non-packaged processes of users have no access to the "C:\Program Files\WindowsApps" directory, this addition to PATH perhaps does not cause problems. However, if wt.exe is run as administrator, then the PATH addition could cause a process in the terminal session to load DLLs from the installation directory of Windows Terminal Preview. (If a packaged application is run within the terminal session, then that too would have access to the directory, but Search Order for Windows Store apps looks like the PATH environment variable will not affect DLL loading in that case.)

Related to https://github.com/microsoft/terminal/pull/6860, https://github.com/microsoft/terminal/issues/6748, https://github.com/microsoft/terminal/issues/7188. Found while searching for possible causes of https://github.com/microsoft/terminal/issues/7195.

Originally created by @KalleOlaviNiemitalo on GitHub (Aug 6, 2020). # Environment ```none Windows build number: Microsoft Windows [Version 10.0.19041.388] Windows Terminal version (if applicable): Windows Terminal Preview 1.2.2022.0 ``` # Steps to reproduce 1. Enable the `wt.exe` app execution alias of Windows Terminal Preview. 2. Press <kbd>Windows</kbd>+<kbd>R</kbd> to open the <samp>Run</samp> dialog box. 3. Type `wt.exe` and press <kbd>Enter</kbd> to start Windows Terminal Preview. 4. In Windows Terminal Preview, start the Command Prompt profile. 5. In the Command Prompt session, type `PATH` and press <kbd>Enter</kbd>. # Expected behavior The displayed value of PATH does not include the directory where Windows Terminal Preview was installed. # Actual behavior `C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.2.2022.0_x64__8wekyb3d8bbwe` is the first directory in PATH. # Notes This is presumably caused by the Registry values that were created by AppXSvc when Windows Terminal Preview was installed: ``` Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe] @="C:\\Program Files\\WindowsApps\\Microsoft.WindowsTerminalPreview_1.2.2022.0_x64__8wekyb3d8bbwe\\wt.exe" "Path"="C:\\Program Files\\WindowsApps\\Microsoft.WindowsTerminalPreview_1.2.2022.0_x64__8wekyb3d8bbwe" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe] @="C:\\Program Files\\WindowsApps\\Microsoft.WindowsTerminalPreview_1.2.2022.0_x64__8wekyb3d8bbwe\\wt.exe" "Path"="C:\\Program Files\\WindowsApps\\Microsoft.WindowsTerminalPreview_1.2.2022.0_x64__8wekyb3d8bbwe" ``` According to [Application Registration](<https://docs.microsoft.com/windows/win32/shell/app-registration#using-the-app-paths-subkey> "Application Registration - Win32 apps | Microsoft Docs"), ShellExecuteEx prepends the data of the "Path" Registry value to the PATH environment variable of the new process. That seems unnecessary here, as selecting Windows Terminal Preview from the Start menu does not add to PATH. Because non-packaged processes of users have no access to the "C:\Program Files\WindowsApps" directory, this addition to PATH perhaps does not cause problems. However, if `wt.exe` is run as administrator, then the PATH addition could cause a process in the terminal session to load DLLs from the installation directory of Windows Terminal Preview. (If a packaged application is run within the terminal session, then that too would have access to the directory, but [Search Order for Windows Store apps](https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#search-order-for-windows-store-apps) looks like the PATH environment variable will not affect DLL loading in that case.) Related to <https://github.com/microsoft/terminal/pull/6860>, <https://github.com/microsoft/terminal/issues/6748>, <https://github.com/microsoft/terminal/issues/7188>. Found while searching for possible causes of <https://github.com/microsoft/terminal/issues/7195>.
claunia commented 2026-01-31 02:10:56 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 6, 2020):

So, a few notes.

  • I think this is harmless. There's no executable in our package that the user shouldn't be able to launch, and nothing that will incorrectly eclipse things that are on their PATHs.
  • We don't have any control over this.
  • I can't find this entry in PATH when I elevate wt.exe
  • Packaged applications don't follow the traditional DLL search order, so I don't think it likely that they'll inherit WT's libraries
@DHowett commented on GitHub (Aug 6, 2020): So, a few notes. * I think this is harmless. There's no executable in our package that the user shouldn't be able to launch, and nothing that will incorrectly eclipse things that _are_ on their `PATH`s. * We don't have any control over this. * I can't find this entry in `PATH` when I elevate wt.exe * Packaged applications don't follow the traditional DLL search order, so I don't think it likely that they'll inherit WT's libraries
claunia commented 2026-01-31 02:10:56 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 6, 2020):

Incidentally, this and the last seven issues are the first (and second through seventh) times I've ever heard of App Paths, and I didn't know the system was maintaining it on our behalf.

@DHowett commented on GitHub (Aug 6, 2020): Incidentally, this and the last seven issues are the first (and second through seventh) times I've ever heard of `App Paths`, and I didn't know the system was maintaining it on our behalf.
claunia commented 2026-01-31 02:10:56 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Aug 6, 2020):

  • I can't find this entry in PATH when I elevate wt.exe

How do you elevate it? If I type wt.exe in the Run dialog box and press Ctrl+Shift+Enter, then the WT installation directory does appear in PATH in the Command Prompt session.

@KalleOlaviNiemitalo commented on GitHub (Aug 6, 2020): > * I can't find this entry in `PATH` when I elevate wt.exe How do you elevate it? If I type `wt.exe` in the <samp>Run</samp> dialog box and press Ctrl+Shift+Enter, then the WT installation directory does appear in PATH in the Command Prompt session.
claunia commented 2026-01-31 02:10:56 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 6, 2020):

Yep, using Ctrl+Shift+Enter from the Run dialog.

@DHowett commented on GitHub (Aug 6, 2020): Yep, using <kbd>Ctrl+Shift+Enter</kbd> from the Run dialog.
claunia commented 2026-01-31 02:10:56 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Aug 6, 2020):

We don't have any control over this.

I imagine Windows Terminal could explicitly delete its installation directory from PATH in the environment block that it passes to CreateProcess.

Or use CreateEnvironmentBlock as suggested in https://github.com/microsoft/terminal/issues/1125, instead of copying PATH and other variables from the environment of the WindowsTerminal.exe process.

Yep, using Ctrl+Shift+Enter from the Run dialog.

That's strange… Are you using the same version of Windows 10? Does the PATH change even get to the WindowsTerminal.exe process? Process Monitor filtering with Operation = Process Start is handy for checking this.

@KalleOlaviNiemitalo commented on GitHub (Aug 6, 2020): > We don't have any control over this. I imagine Windows Terminal could explicitly delete its installation directory from PATH in the environment block that it passes to CreateProcess. Or use CreateEnvironmentBlock as suggested in <https://github.com/microsoft/terminal/issues/1125>, instead of copying PATH and other variables from the environment of the WindowsTerminal.exe process. > Yep, using Ctrl+Shift+Enter from the Run dialog. That's strange… Are you using the same version of Windows 10? Does the PATH change even get to the WindowsTerminal.exe process? Process Monitor filtering with Operation = Process Start is handy for checking this.
claunia commented 2026-01-31 02:10:56 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 26, 2020):

:tada:This issue was addressed in #7243, which has now been successfully released as Windows Terminal Preview v1.3.2382.0.🎉

Handy links:

@ghost commented on GitHub (Aug 26, 2020): :tada:This issue was addressed in #7243, which has now been successfully released as `Windows Terminal Preview v1.3.2382.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.3.2382.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
claunia commented 2026-01-31 02:10:56 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Sep 3, 2020):

https://github.com/microsoft/terminal/pull/7243 did not fix this for the following child processes:

  • the editor that Windows Terminal starts for editing settings.json (and presumably defaults.json)
  • C:\WINDOWS\system32\wsl.exe --list
  • Web browser processes started by the Feedback menu item or by hyperlinks on the About screen

According to https://github.com/microsoft/terminal/issues/7460, the extra entry in Path interferes with the loading of vcruntime140.dll from other directories in Path, if C:\Windows\System32\VCRUNTIME140.dll does not exist.

Please reopen.

@KalleOlaviNiemitalo commented on GitHub (Sep 3, 2020): <https://github.com/microsoft/terminal/pull/7243> did not fix this for the following child processes: * the editor that Windows Terminal starts for editing `settings.json` (and presumably `defaults.json`) * `C:\WINDOWS\system32\wsl.exe --list` * Web browser processes started by the Feedback menu item or by hyperlinks on the About screen According to <https://github.com/microsoft/terminal/issues/7460>, the extra entry in `Path` interferes with the loading of `vcruntime140.dll` from other directories in `Path`, if `C:\Windows\System32\VCRUNTIME140.dll` does not exist. Please reopen.
claunia commented 2026-01-31 02:10:57 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 4, 2020):

Huh.

@DHowett commented on GitHub (Sep 4, 2020): _Huh._
claunia commented 2026-01-31 02:10:57 +00:00
Author
Owner
Copy Link

@JustinGrote commented on GitHub (Sep 24, 2020):

@DHowett not sure if this is related but when I do Win+R then wt.exe, currently getting this:
image

EDIT: It was this problem. I deleted the above registry keys and restarted, put the wt preview in my path, and everything works fine.

@JustinGrote commented on GitHub (Sep 24, 2020): @DHowett not sure if this is related but when I do `Win+R` then `wt.exe`, currently getting this: ![image](https://user-images.githubusercontent.com/15258962/94107592-adeb1880-fdf2-11ea-8930-e2afed95d8d0.png) EDIT: It was this problem. I deleted the above registry keys and restarted, put the wt preview in my path, and everything works fine.
claunia commented 2026-01-31 02:10:57 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Jan 13, 2022):

Retested with Windows Terminal Preview 1.12.3472.0 on Windows 10.0.19044.1415:

  • 🆗 The Command Prompt session in the tab does not inherit the extra PATH.
  • 🆗 No wsl.exe --list process is started.
  • 🆗 The wsl.exe -d Debian process does not inherit the extra PATH.
  • ⚠️ The Web browser process started by the Documentation link in the About dialog box inherits the extra path.
  • ⚠️ The JSON file editor inherits the extra path.
@KalleOlaviNiemitalo commented on GitHub (Jan 13, 2022): Retested with Windows Terminal Preview 1.12.3472.0 on Windows 10.0.19044.1415: * :ok: The Command Prompt session in the tab does not inherit the extra PATH. * :ok: No `wsl.exe --list` process is started. * :ok: The `wsl.exe -d Debian` process does not inherit the extra PATH. * :warning: The Web browser process started by the Documentation link in the About dialog box inherits the extra path. * :warning: The JSON file editor inherits the extra path.
claunia commented 2026-01-31 02:10:57 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 28, 2022):

Merging notes:

I can reproduce this, but it is not specific to WSL.

  1. Pin Windows Terminal Preview 1.15.2002.0 to the task bar on Windows 10.0.19044.1826. (maintainer note: also repros on Win11)
  2. Set Command Prompt as the default profile.
  3. Close Windows Terminal Preview.
  4. Start Windows Terminal Preview by left-clicking the task-bar button.
  5. Execute PATH in the Command Prompt session. The output does not include the Windows Terminal Preview installation directory. ✅
  6. Open another tab by right-clicking the task-bar button and left-clicking the "Command Prompt" task.
  7. Execute PATH in the Command Prompt session in the second tab. The output does not include the Windows Terminal Preview installation directory. ✅
  8. Close Windows Terminal Preview.
  9. Start Windows Terminal Preview by right-clicking the task-bar button and left-clicking the "Command Prompt" task.
  10. Execute PATH in the Command Prompt session. The output starts with Windows Terminal Preview installation directory. ❌
  11. Open another tab by right-clicking the task-bar button and left-clicking the "Command Prompt" task.
  12. Execute PATH in the Command Prompt session in the second tab. The output starts with Windows Terminal Preview installation directory. ❌

Probably also related:
https://github.com/microsoft/terminal/issues/7188#issuecomment-669046854

I can reproduce with Windows Terminal 1.1.2021.0 and Windows Terminal Preview 1.2.2022.0 on Windows 10 version 2004 (OS Build 19041.388):

  • If I enable the wt.exe app execution alias of Windows Terminal Preview, then wt in File Explorer starts Windows Terminal Preview. ✔
  • If I enable the wt.exe app execution alias of Windows Terminal, then wt in File Explorer shows the access-denied dialog box. ❌
  • If I disable both wt.exe app execution aliases, then wt in File Explorer shows the access-denied dialog box. 🙄 In this case though, I shouldn't expect wt to work anyway.

When I install Windows Terminal Preview, AppXSvc creates the following Registry keys:

  • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe

Those Registry keys stay there when I enable or disable the wt.exe app execution aliases. They seem related to #6748 and #6860. If I rename the Registry keys, then the results change:

  • If I enable the wt.exe app execution alias of Windows Terminal Preview, then wt in File Explorer runs Windows Terminal Preview. ✔
  • If I enable the wt.exe app execution alias of Windows Terminal, then wt in File Explorer runs Windows Terminal. ✔
  • If I disable both wt.exe app execution aliases, then wt in File Explorer opens http://wt/ in my Web browser. 🙄

If I disable the skype.exe app execution alias and type skype.exe in the Windows+R run box or in the File Explorer address bar, then I get a similar access-denied dialog box, so this is not specific to Windows Terminal.

If Windows needs a Registry key in App Paths, then perhaps it should keep the per-user key always synchronized with the app execution aliases, and not create the per-machine key.

So, we added wt.exe to the package[1], so that the alias could point at an exe with the same literal name. But that caused MORE issues. Sometimes, the package's install directory is prepended to the path. That causes the OS to load the wt from inside WindowsApps, instead of the actual alias.

dupes?

internal work

  • MSFT:28217948 was duped to MSFT:29353059 which was fixed in os.2020!5514481, which should have shipped in 21307, around the time of Windows 11.

here's my understanding:
image
I believe that bad ACLs on WindowsApps can cause the first PERMISSION_DENIED to fail (user was NOT denied access), and bad ACLs on the WindowsTerminal package can cause the "Try Again" to fail (Package-ID-Token was rejected?)

Conclusions:

  • "Win+R / Explorer.exe failed to start wt.exe": That should probably be fixed in Windows 11
  • **"wt is launched with C:\Program Files\WindowsApps\Microsoft.WindowsTerminal* prepended to the path: We should probably just cut that out of the PATH ourselves, if we see it. It'll do no good.

[1]: See #6860 which was supposed to fix #6625:

It turns out that when an application's alias name doesn't match its filename (as in our case, wt.exe is an alias for WindowsTerminal.exe ), it fails out during elevated launch.

@zadjii-msft commented on GitHub (Jul 28, 2022): _Merging notes:_ > I can reproduce this, but it is not specific to WSL. > > 1. Pin Windows Terminal Preview 1.15.2002.0 to the task bar on Windows 10.0.19044.1826. (maintainer note: also repros on Win11) > 2. Set Command Prompt as the default profile. > 3. Close Windows Terminal Preview. > 4. Start Windows Terminal Preview by left-clicking the task-bar button. > 5. Execute `PATH` in the Command Prompt session. The output does not include the Windows Terminal Preview installation directory. ✅ > 6. Open another tab by right-clicking the task-bar button and left-clicking the "Command Prompt" task. > 7. Execute `PATH` in the Command Prompt session in the second tab. The output does not include the Windows Terminal Preview installation directory. ✅ > 8. Close Windows Terminal Preview. > 9. Start Windows Terminal Preview by right-clicking the task-bar button and left-clicking the "Command Prompt" task. > 10. Execute `PATH` in the Command Prompt session. The output starts with Windows Terminal Preview installation directory. ❌ > 11. Open another tab by right-clicking the task-bar button and left-clicking the "Command Prompt" task. > 12. Execute `PATH` in the Command Prompt session in the second tab. The output starts with Windows Terminal Preview installation directory. ❌ > Probably also related: https://github.com/microsoft/terminal/issues/7188#issuecomment-669046854 > I can reproduce with Windows Terminal 1.1.2021.0 and Windows Terminal Preview 1.2.2022.0 on Windows 10 version 2004 (OS Build 19041.388): > > * If I enable the `wt.exe` app execution alias of Windows Terminal Preview, then `wt` in File Explorer starts Windows Terminal Preview. ✔ > * If I enable the `wt.exe` app execution alias of Windows Terminal, then `wt` in File Explorer shows the access-denied dialog box. ❌ > * If I disable both `wt.exe` app execution aliases, then `wt` in File Explorer shows the access-denied dialog box. 🙄 In this case though, I shouldn't expect `wt` to work anyway. > > When I install Windows Terminal Preview, AppXSvc creates the following Registry keys: > > * HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe > * HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe > > Those Registry keys stay there when I enable or disable the `wt.exe` app execution aliases. They seem related to #6748 and #6860. If I rename the Registry keys, then the results change: > > * If I enable the `wt.exe` app execution alias of Windows Terminal Preview, then `wt` in File Explorer runs Windows Terminal Preview. ✔ > * If I enable the `wt.exe` app execution alias of Windows Terminal, then `wt` in File Explorer runs Windows Terminal. ✔ > * If I disable both `wt.exe` app execution aliases, then `wt` in File Explorer opens `http://wt/` in my Web browser. 🙄 > > If I disable the `skype.exe` app execution alias and type `skype.exe` in the Windows+R run box or in the File Explorer address bar, then I get a similar access-denied dialog box, so this is not specific to Windows Terminal. > > If Windows needs a Registry key in App Paths, then perhaps it should keep the per-user key always synchronized with the app execution aliases, and not create the per-machine key. So, we added `wt.exe` to the package[1], so that the alias could point at an exe with the same literal name. But that caused MORE issues. Sometimes, the package's install directory is prepended to the path. That causes the OS to load the `wt` from inside `WindowsApps`, instead of the actual alias. ### dupes? * #12640 * #13460 * #7188 * #11777 ### internal work * MSFT:28217948 was duped to MSFT:29353059 which was fixed in os.2020!5514481, which should have shipped in 21307, around the time of Windows 11. > here's my understanding: > ![image](https://user-images.githubusercontent.com/18356694/181573796-02fd4eb4-6e77-470a-9b34-771ef4222237.png) > I believe that bad ACLs on WindowsApps can cause the first PERMISSION_DENIED to fail (user was NOT denied access), and bad ACLs on the WindowsTerminal package can cause the "Try Again" to fail (Package-ID-Token was rejected?) ### Conclusions: * **"Win+R / Explorer.exe failed to start `wt.exe`"**: That should probably be fixed in Windows 11 * **"wt is launched with `C:\Program Files\WindowsApps\Microsoft.WindowsTerminal*` prepended to the path: We should probably just cut that out of the PATH ourselves, if we see it. It'll do no good. [1]: See #6860 which was supposed to fix #6625: > It turns out that when an application's _alias name_ doesn't match its _filename_ (as in our case, `wt.exe` is an alias for `WindowsTerminal.exe `), it fails out during elevated launch.
claunia commented 2026-01-31 02:10:58 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 21, 2023):

A thought: This might have been fixed by #14999.

@zadjii-msft commented on GitHub (Mar 21, 2023): A thought: This might have been fixed by #14999.
claunia commented 2026-01-31 02:10:58 +00:00
Author
Owner
Copy Link

@ianjoneill commented on GitHub (Mar 22, 2023):

A thought: This might have been fixed by #14999.

Yep - looks like it:

image

And if I set compatibility.reloadEnvironmentVariables to false:

image

@ianjoneill commented on GitHub (Mar 22, 2023): > A thought: This might have been fixed by #14999. Yep - looks like it: ![image](https://user-images.githubusercontent.com/5821575/226851102-517daefe-65af-49e1-ac23-8b463bc33290.png) And if I set `compatibility.reloadEnvironmentVariables` to `false`: ![image](https://user-images.githubusercontent.com/5821575/226851359-896a10fe-46ab-4460-9321-284d87279099.png)
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 Area-TerminalConnection Culprit-Centennial Issue-Bug Priority-2 Product-Terminal Resolution-Fix-Committed
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#10036
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?