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

Cannot scroll buffer in Terminal with inbox telnet client #8366

New Issue
Open
opened 2026-01-31 01:27:39 +00:00 by claunia · 29 comments
claunia commented 2026-01-31 01:27:39 +00:00
Owner
Copy Link

Originally created by @sierrab1989 on GitHub (May 20, 2020).

Hi, I love the new Windows Terminal. I've manage to add my routers and switches to it but the only issue I have is that I can't scroll. Once I log into my switch using ssh, I can't seem to scroll up to see what's above. Kindly let me know how I can activate scrolling.
PS. scrolling works for regular CMD or PowerShell.

Originally created by @sierrab1989 on GitHub (May 20, 2020). Hi, I love the new Windows Terminal. I've manage to add my routers and switches to it but the only issue I have is that I can't scroll. Once I log into my switch using ssh, I can't seem to scroll up to see what's above. Kindly let me know how I can activate scrolling. PS. scrolling works for regular CMD or PowerShell.
claunia added the Help WantedArea-OutputIssue-BugProduct-ConptyPriority-2 labels 2026-01-31 01:27:39 +00:00
claunia commented 2026-01-31 01:27:40 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 20, 2020):

Hi, please make sure you're using the bug report template when you file issues.

What SSH client are you using?

@DHowett commented on GitHub (May 20, 2020): Hi, please make sure you're using the bug report template when you file issues. What SSH client are you using?
claunia commented 2026-01-31 01:27:41 +00:00
Author
Owner
Copy Link

@sierrab1989 commented on GitHub (May 21, 2020):

Hi Dustin,
Actually I'm able to scroll through on SSH logins. I'm currently using the
OpenSSH Beta. It's with Telnet that I'm not able to scroll.

Regards,

@sierrab1989 commented on GitHub (May 21, 2020): Hi Dustin, Actually I'm able to scroll through on SSH logins. I'm currently using the OpenSSH Beta. It's with Telnet that I'm not able to scroll. Regards,
claunia commented 2026-01-31 01:27:41 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 21, 2020):

Cool. Which telnet client?

@DHowett commented on GitHub (May 21, 2020): Cool. Which telnet client?
claunia commented 2026-01-31 01:27:41 +00:00
Author
Owner
Copy Link

@sierrab1989 commented on GitHub (May 21, 2020):

for telnet i'm using the one that you add on the windows feature.

@sierrab1989 commented on GitHub (May 21, 2020): for telnet i'm using the one that you add on the windows feature.
claunia commented 2026-01-31 01:27:42 +00:00
Author
Owner
Copy Link

@shermp commented on GitHub (May 28, 2020):

Hi, I'd just like to state that I'm seeing the same issue.

I'm using Terminal 1.0.1401.0

It's only happening with telnet, not SSH. I'm using the inbuilt Windows 10 telnet client.

It happens with both PowerShell and Command Prompt running in Terminal. I can successfully scroll using the old Console, with both Command Prompt and PowerShell.

I hope this helps.

@shermp commented on GitHub (May 28, 2020): Hi, I'd just like to state that I'm seeing the same issue. I'm using Terminal 1.0.1401.0 It's only happening with telnet, not SSH. I'm using the inbuilt Windows 10 telnet client. It happens with both PowerShell and Command Prompt running in Terminal. I can successfully scroll using the old Console, with both Command Prompt and PowerShell. I hope this helps.
claunia commented 2026-01-31 01:27:42 +00:00
Author
Owner
Copy Link

@JunhwanPark commented on GitHub (Jun 11, 2020):

Hi,
I'm using Teminal Preview 1.0.1402.0

  • Power Shell
> ssh junhwan@dell2
$ vi test.cpp

After connecting to ssh, when I edit the source with vi (vim), when I scroll the mouse, strange characters are displayed. I haven't experienced it in other ssh tools.

I use the set mouse=a option in the .vimrc file. This happens when using this option.

@JunhwanPark commented on GitHub (Jun 11, 2020): Hi, I'm using Teminal Preview 1.0.1402.0 - Power Shell ``` > ssh junhwan@dell2 $ vi test.cpp ``` After connecting to ssh, when I edit the source with vi (vim), when I scroll the mouse, strange characters are displayed. I haven't experienced it in other ssh tools. I use the `set mouse=a` option in the `.vimrc` file. This happens when using this option.
claunia commented 2026-01-31 01:27:43 +00:00
Author
Owner
Copy Link

@szsong commented on GitHub (Jul 29, 2020):

Any chance getting this as higher priority? This is a bug that breaks compatibility with Microsoft's own existing functionality (telnet) and it could be a blocking bug that forces people dropping Terminal :(

@szsong commented on GitHub (Jul 29, 2020): Any chance getting this as higher priority? This is a bug that breaks compatibility with Microsoft's own existing functionality (telnet) and it could be a blocking bug that forces people dropping Terminal :(
claunia commented 2026-01-31 01:27:43 +00:00
Author
Owner
Copy Link

@Elinpf commented on GitHub (Sep 10, 2020):

Is there the latest development of this bug?

@Elinpf commented on GitHub (Sep 10, 2020): Is there the latest development of this bug?
claunia commented 2026-01-31 01:27:43 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 10, 2020):

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?
image
That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

@zadjii-msft commented on GitHub (Sep 10, 2020): Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button? ![image](https://user-images.githubusercontent.com/18356694/91237459-5cbb0c80-e700-11ea-9347-b9b1ec2813b1.png) That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️
claunia commented 2026-01-31 01:27:44 +00:00
Author
Owner
Copy Link

@cjsakfh89 commented on GitHub (Jan 28, 2021):

It still not fixed...

@cjsakfh89 commented on GitHub (Jan 28, 2021): It still not fixed...
claunia commented 2026-01-31 01:27:44 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 28, 2021):

@cjsakfh89 Nope, hence why this issue is still open. We'll make sure to update this thread when there is any progress. In the meantime, might I recommend the Subscribe button?
image
That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

@zadjii-msft commented on GitHub (Jan 28, 2021): @cjsakfh89 Nope, hence why this issue is still open. We'll make sure to update this thread when there is any progress. In the meantime, might I recommend the Subscribe button? ![image](https://user-images.githubusercontent.com/18356694/91237459-5cbb0c80-e700-11ea-9347-b9b1ec2813b1.png) That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️
claunia commented 2026-01-31 01:27:44 +00:00
Author
Owner
Copy Link

@pmonajem commented on GitHub (May 10, 2021):

Folks please prioritize this item, this is rendering the app useless for many networking tasks.
I've noticed the VS Code integrated terminal is working fine but Windows Terminal is broken, interestingly enough.

@pmonajem commented on GitHub (May 10, 2021): Folks please prioritize this item, this is rendering the app useless for many networking tasks. I've noticed the VS Code integrated terminal is working fine but Windows Terminal is broken, interestingly enough.
claunia commented 2026-01-31 01:27:45 +00:00
Author
Owner
Copy Link

@tarekeldeeb commented on GitHub (Jun 9, 2021):

Is there any workaround for this issue?

@tarekeldeeb commented on GitHub (Jun 9, 2021): Is there any workaround for this issue?
claunia commented 2026-01-31 01:27:45 +00:00
Author
Owner
Copy Link

@shadow1163 commented on GitHub (Jul 30, 2021):

same issue with version 1.9.1942.0

@shadow1163 commented on GitHub (Jul 30, 2021): same issue with version 1.9.1942.0
claunia commented 2026-01-31 01:27:45 +00:00
Author
Owner
Copy Link

@shaunthorne commented on GitHub (Oct 10, 2021):

Is there any workaround for this issue?

I found a temporary solution. Plink from PuTTY works acceptable in this case.

As mentioned in PuTTY documentation, "Plink is probably not what you want if you want to run an interactive session in a console window" but it works with Windows Terminal even better than native MS telnet.exe

@shaunthorne commented on GitHub (Oct 10, 2021): > Is there any workaround for this issue? I found a temporary solution. Plink from PuTTY works acceptable in this case. As mentioned in PuTTY documentation, "_Plink is probably not what you want if you want to run an interactive session in a console window_" but it works with Windows Terminal even better than native MS telnet.exe
claunia commented 2026-01-31 01:27:46 +00:00
Author
Owner
Copy Link

@mosebac commented on GitHub (Nov 24, 2021):

Hi,

I confirm @shaunthorne 's workaround is working and is an acceptable solution in this case.

I've been trying to use Windows Terminal as the default console application for GNS3 network simulation software, and had the same buffering issues everyone is talking about.
Using Plink works like a charm : wt -w0 split-pane --tabColor #C678DD --colorScheme "One Half Dark" --title %d --suppressApplicationTitle plink -telnet -P %p %h

thx

@mosebac commented on GitHub (Nov 24, 2021): Hi, I confirm @shaunthorne 's workaround is working and is an acceptable solution in this case. I've been trying to use Windows Terminal as the default console application for GNS3 network simulation software, and had the same buffering issues everyone is talking about. Using Plink works like a charm : wt -w0 split-pane --tabColor #C678DD --colorScheme "One Half Dark" --title %d --suppressApplicationTitle plink -telnet -P %p %h thx
claunia commented 2026-01-31 01:27:46 +00:00
Author
Owner
Copy Link

@eddie813022 commented on GitHub (Jan 4, 2022):

Hi
is there are any update further updates?
my windows terminal version 1.11.3471.0 have same problem
thanks

@eddie813022 commented on GitHub (Jan 4, 2022): Hi is there are any update further updates? my windows terminal version 1.11.3471.0 have same problem thanks
claunia commented 2026-01-31 01:27:46 +00:00
Author
Owner
Copy Link

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

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?
image
That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

@zadjii-msft commented on GitHub (Jan 4, 2022): Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button? ![image](https://user-images.githubusercontent.com/18356694/91237459-5cbb0c80-e700-11ea-9347-b9b1ec2813b1.png) That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️
claunia commented 2026-01-31 01:27:47 +00:00
Author
Owner
Copy Link

@PetSerAl commented on GitHub (Feb 5, 2022):

I have the same issue with build-in telnet client. And I think, that I understand reasons for that behavior. Windows console have such thing as screen buffers and build-in telnet client use them. Also old console window does not actually have scroll-back buffer: all scrollable region is part of screen buffer, while in Windows Terminal screen buffer have size of the window.
So you loose scroll-back because it leaves screen buffer, and it is very likely that build-in telnet client updates its screen buffer in such way, that it prevents Windows Terminal from capture scroll-back. For example, when remote side disconnect telnet session, as build-in telnet client display message about that, top four lines of remote session console screen get captured in scroll-back by Windows Terminal.

@PetSerAl commented on GitHub (Feb 5, 2022): I have the same issue with build-in telnet client. And I think, that I understand reasons for that behavior. Windows console have such thing as [screen buffers](https://docs.microsoft.com/en-us/windows/console/console-screen-buffers) and build-in telnet client use them. Also old console window does not actually have scroll-back buffer: all scrollable region is part of screen buffer, while in Windows Terminal screen buffer have size of the window. So you loose scroll-back because it leaves screen buffer, and it is very likely that build-in telnet client updates its screen buffer in such way, that it prevents Windows Terminal from capture scroll-back. For example, when remote side disconnect telnet session, as build-in telnet client display message about that, top four lines of remote session console screen get captured in scroll-back by Windows Terminal.
claunia commented 2026-01-31 01:27:47 +00:00
Author
Owner
Copy Link

@tatroc commented on GitHub (Jul 14, 2022):

The work around I used was wsl.
wsl ~ --exec telnet 10.77.77.2

I saw others mention using plink, but when I control+c, plink would exit. Using WSL + telnet does not have this issue.

@tatroc commented on GitHub (Jul 14, 2022): The work around I used was wsl. `wsl ~ --exec telnet 10.77.77.2` I saw others mention using plink, but when I control+c, plink would exit. Using WSL + telnet does not have this issue.
claunia commented 2026-01-31 01:27:47 +00:00
Author
Owner
Copy Link

@erh-git commented on GitHub (Sep 1, 2022):

The work around I used was wsl. wsl ~ --exec telnet 10.77.77.2

For those of you here trying to get GNS3 to use the new Windows Terminal (like me), I just want to leave a note to spare you the hours of frustration I spent trying to get it to work.

The command above launches the default WSL instance -- for me, this was a WSL2 instance. The WSL2 instance runs on a special/hidden virtual Switch, while the GNS3 VM on Hyper-V runs on the Default Switch. Communication between these two switches is restricted.

The solution is to install a WSL1 instance and specify that instance in the console application:

wsl --install -d Debian
wsl --set-version Debian 1

(use whichever distro you like, note that for Debian I had to sudo apt-get install telnet as well)

Then use this Distro to launch your telnet sessions: wsl.exe -d Debian telnet 10.77.77.2

(I don't know the significance of including or omitting ~ --exec, in my testing the results were the same)

My final GNS3 Console Command looked like this: wt.exe -w 0 --suppressApplicationTitle --title %d wsl.exe -d Debian telnet %h %p

@erh-git commented on GitHub (Sep 1, 2022): > The work around I used was wsl. `wsl ~ --exec telnet 10.77.77.2` For those of you here trying to get GNS3 to use the new Windows Terminal (like me), I just want to leave a note to spare you the hours of frustration I spent trying to get it to work. The command above launches the _default_ WSL instance -- for me, this was a **WSL2** instance. The WSL2 instance runs on a special/hidden virtual Switch, while the GNS3 VM on Hyper-V runs on the Default Switch. Communication between these two switches is restricted. The solution is to install a **WSL1** instance and specify that instance in the console application: ``` wsl --install -d Debian wsl --set-version Debian 1 ``` *(use whichever distro you like, note that for Debian I had to `sudo apt-get install telnet` as well)* Then use this Distro to launch your telnet sessions: `wsl.exe -d Debian telnet 10.77.77.2` *(I don't know the significance of including or omitting `~ --exec`, in my testing the results were the same)* My final GNS3 Console Command looked like this: `wt.exe -w 0 --suppressApplicationTitle --title %d wsl.exe -d Debian telnet %h %p`
claunia commented 2026-01-31 01:27:48 +00:00
Author
Owner
Copy Link

@islandsins commented on GitHub (Jan 13, 2023):

Now that terminal is the default on 22H2 this is a major issue. Please prioritise this issue

@islandsins commented on GitHub (Jan 13, 2023): Now that terminal is the default on 22H2 this is a major issue. Please prioritise this issue
claunia commented 2026-01-31 01:27:48 +00:00
Author
Owner
Copy Link

@YoruguaDEV commented on GitHub (Jan 23, 2023):

Hello!
Any news?
i have the same problem when i try to manage my cisco switch via telnet or ssh...
now terminal is the default...

@YoruguaDEV commented on GitHub (Jan 23, 2023): Hello! Any news? i have the same problem when i try to manage my cisco switch via telnet or ssh... now terminal is the default...
claunia commented 2026-01-31 01:27:48 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 23, 2023):

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?
image
That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

@zadjii-msft commented on GitHub (Jan 23, 2023): [Nope. We'll make sure to update this thread when there is](https://github.com/microsoft/terminal/issues/6056#issuecomment-1004726622). In the meantime, might I recommend the Subscribe button? ![image](https://user-images.githubusercontent.com/18356694/91237459-5cbb0c80-e700-11ea-9347-b9b1ec2813b1.png) That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️
claunia commented 2026-01-31 01:27:48 +00:00
Author
Owner
Copy Link

@Blackers33 commented on GitHub (Apr 9, 2024):

Hi,

I confirm @shaunthorne 's workaround is working and is an acceptable solution in this case.

I've been trying to use Windows Terminal as the default console application for GNS3 network simulation software, and had the same buffering issues everyone is talking about. Using Plink works like a charm : wt -w0 split-pane --tabColor #C678DD --colorScheme "One Half Dark" --title %d --suppressApplicationTitle plink -telnet -P %p %h

thx

This solution is not satisfying because plink does not offer command history with arrow up and down.

the original issue has not been solved yet.

@Blackers33 commented on GitHub (Apr 9, 2024): > Hi, > > I confirm @shaunthorne 's workaround is working and is an acceptable solution in this case. > > I've been trying to use Windows Terminal as the default console application for GNS3 network simulation software, and had the same buffering issues everyone is talking about. Using Plink works like a charm : wt -w0 split-pane --tabColor #C678DD --colorScheme "One Half Dark" --title %d --suppressApplicationTitle plink -telnet -P %p %h > > thx This solution is not satisfying because plink does not offer command history with arrow up and down. the original issue has not been solved yet.
claunia commented 2026-01-31 01:27:48 +00:00
Author
Owner
Copy Link

@nukoseer commented on GitHub (Aug 29, 2024):

I spent some time trying to figure out what's going on under the hood about this telnet issue. What I see is that normally when we press RET on an empty terminal the LINE FEED (\r\n) sequences are usually sent along with some VT sequences (for placing the cursor etc.). I think the LINE FEED sequences are eventually used to set the viewport position (the request reaches up to Terminal::SetViewportPosition) when the viewport becomes larger than window, and after this point we are able to scrollback by moving the viewport. However, when I send RET while telnet is running, some VT sequences are sent, but there is no LINE FEED sequence, which means there will be no calculation effecting viewport(?). The viewport will always be at its default size and there will be no way to scrollback.

Here are sequences I get with and without telnet (I read them from Terminal::Write in Terminal.cpp).

telnet on CMD:

  • \x1b7\x1b[0m\x1b[2;1;30;120;;1;1$v\x1b[32;30;1;30;120$x\x1b8
  • \x1b[30;1H
  • \x1b[30;1H\x1b7\x1b[30;1H\x1b[0mnukoseer@nukoseer:~$ \x1b8\x1b7\x1b[30;1H\x1b[0mnukoseer@nukoseer:~$ \x1b8\x1b7\x1b[0m\x1b[2;1;30;120;;1;1$v\x1b[32;30;1;30;120$x\x1b8\x1b[30;1H\x1b7\x1b[30;1H\x1b[0mnukoseer@nukoseer:~$ \x1b8\x1b7\x1b[30;1H\x1b[0mnukoseer@nukoseer:~$ \x1b8\x1b[30;22H

CMD:

  • \x1b[4;13H
  • \r\n
  • C:\\Users\\PC>

I don't know if this is helpful at all, but just wanted to share my findings.

@nukoseer commented on GitHub (Aug 29, 2024): I spent some time trying to figure out what's going on under the hood about this `telnet` issue. What I see is that normally when we press `RET` on an empty terminal the `LINE FEED` (`\r\n`) sequences are usually sent along with some VT sequences (for placing the cursor etc.). I think the `LINE FEED` sequences are eventually used to set the viewport position (the request reaches up to `Terminal::SetViewportPosition`) when the viewport becomes larger than window, and after this point we are able to scrollback by moving the viewport. However, when I send `RET` while `telnet` is running, some VT sequences are sent, but there is no `LINE FEED` sequence, which means there will be no calculation effecting viewport(?). The viewport will always be at its default size and there will be no way to scrollback. Here are sequences I get with and without `telnet` (I read them from `Terminal::Write` in `Terminal.cpp`). `telnet` on CMD: - `\x1b7\x1b[0m\x1b[2;1;30;120;;1;1$v\x1b[32;30;1;30;120$x\x1b8` - `\x1b[30;1H` - `\x1b[30;1H\x1b7\x1b[30;1H\x1b[0mnukoseer@nukoseer:~$ \x1b8\x1b7\x1b[30;1H\x1b[0mnukoseer@nukoseer:~$ \x1b8\x1b7\x1b[0m\x1b[2;1;30;120;;1;1$v\x1b[32;30;1;30;120$x\x1b8\x1b[30;1H\x1b7\x1b[30;1H\x1b[0mnukoseer@nukoseer:~$ \x1b8\x1b7\x1b[30;1H\x1b[0mnukoseer@nukoseer:~$ \x1b8\x1b[30;22H` CMD: - `\x1b[4;13H` - `\r\n` - `C:\\Users\\PC>` _I don't know if this is helpful at all, but just wanted to share my findings._
claunia commented 2026-01-31 01:27:49 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 29, 2024):

I also don't know if this just magically got better after 1.22, with the big-ol conpty rewrite.

@zadjii-msft commented on GitHub (Aug 29, 2024): I also don't know if this just magically got better after 1.22, with the big-ol conpty rewrite.
claunia commented 2026-01-31 01:27:49 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Aug 29, 2024):

I think nukoseer's log above is evidence that they're already using the new conpty rewrite. It appears that the Windows telnet client is scrolling the buffer with a ScrollConsoleScreenBuffer call, which we're now translating into a copy rectangle (DECCRA) sequence. That's the \x1b[2;1;30;120;;1;1$v in that log.

This is no better or worse than it was before (well except that it's now a lot more efficient). The fundamental issue is that the conhost buffer in this situation is the same size as the viewport (as has been previously mentioned), so telnet's attempt to scroll just appears to us like it's copying a block of data within the viewport.

But with the new conpty translation, it might now be possible to detect that as a special case (i.e. a ScrollConsoleScreenBuffer call covering the entire viewport) and map that to a linefeed instead of a DECCRA. I'm not convinced that's a good idea, but it's perhaps something to think about.

@j4james commented on GitHub (Aug 29, 2024): I think nukoseer's log above is evidence that they're already using the new conpty rewrite. It appears that the Windows telnet client is scrolling the buffer with a `ScrollConsoleScreenBuffer` call, which we're now translating into a copy rectangle (`DECCRA`) sequence. That's the `\x1b[2;1;30;120;;1;1$v` in that log. This is no better or worse than it was before (well except that it's now a lot more efficient). The fundamental issue is that the conhost buffer in this situation is the same size as the viewport (as has been previously mentioned), so telnet's attempt to scroll just appears to us like it's copying a block of data within the viewport. But with the new conpty translation, it might now be possible to detect that as a special case (i.e. a `ScrollConsoleScreenBuffer` call covering the entire viewport) and map that to a linefeed instead of a `DECCRA`. I'm not convinced that's a good idea, but it's perhaps something to think about.
claunia commented 2026-01-31 01:27:49 +00:00
Author
Owner
Copy Link

@Mqxx commented on GitHub (Jun 13, 2025):

Any update on this?

@Mqxx commented on GitHub (Jun 13, 2025): Any update on this?
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-Output Help Wanted Issue-Bug Priority-2 Product-Conpty
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#8366
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?