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

Spurious OSC 11 when using tmux over Windows' SSH #22359

New Issue
Closed
opened 2026-01-31 08:10:50 +00:00 by claunia · 25 comments
claunia commented 2026-01-31 08:10:50 +00:00
Owner
Copy Link

Originally created by @lhecker on GitHub (Oct 7, 2024).

Windows Terminal version

1.23.2771.0

Windows build number

10.0.26100.0

Other Software

  • OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2
  • tmux 3.5a

Steps to reproduce

  • Either
    • ssh to a Linux box
    • ssh to WSL (you can get the WSL2 VM IP by running e.g. ip a inside WSL)
  • Run tmux

Expected Behavior

Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
lhecker@server ~>

Actual Behavior

Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
lhecker@server ~> ]11;rgb:0000/0000/0000\

The issue does not occur when ssh'ing to localhost inside WSL.

Originally created by @lhecker on GitHub (Oct 7, 2024). ### Windows Terminal version 1.23.2771.0 ### Windows build number 10.0.26100.0 ### Other Software * OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2 * tmux 3.5a ### Steps to reproduce * Either * ssh to a Linux box * ssh to WSL (you can get the WSL2 VM IP by running e.g. `ip a` inside WSL) * Run tmux ### Expected Behavior ``` Welcome to fish, the friendly interactive shell Type help for instructions on how to use fish lhecker@server ~> ``` ### Actual Behavior ``` Welcome to fish, the friendly interactive shell Type help for instructions on how to use fish lhecker@server ~> ]11;rgb:0000/0000/0000\ ``` The issue does not occur when ssh'ing to localhost inside WSL.
claunia added the Issue-BugArea-VTNeeds-Tag-FixProduct-Terminal labels 2026-01-31 08:10:50 +00:00
claunia commented 2026-01-31 08:10:51 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Oct 7, 2024):

I am so ready to blame win32-openssh already heh

@DHowett commented on GitHub (Oct 7, 2024): I am so ready to blame win32-openssh already heh
claunia commented 2026-01-31 08:10:52 +00:00
Author
Owner
Copy Link

@jaromanda commented on GitHub (Oct 9, 2024):

This "issue" occurred only after I upgraded tmux from 3.4 to 3.5a

@jaromanda commented on GitHub (Oct 9, 2024): This "issue" occurred only after I upgraded tmux from 3.4 to 3.5a
claunia commented 2026-01-31 08:10:52 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Feb 11, 2025):

To easily reproduce issues like this, you can simulate a slow connection with trickle/tritty. For example you can start a shell at 57600 baud with tritty -b 57600, then try running tmux. You'll see a bunch of query responses leaking into the input buffer.

I suspect this is just an escape-time issue, though. Because tmux recently decreased the default time from 500ms to 10ms (see 2e9d7ebf15). I believe that change would have been introduced in version 3.5. Setting the timeout back to 500ms fixes the issue for me.

@j4james commented on GitHub (Feb 11, 2025): To easily reproduce issues like this, you can simulate a slow connection with [trickle/tritty](https://github.com/sjmulder/trickle). For example you can start a shell at 57600 baud with `tritty -b 57600`, then try running tmux. You'll see a bunch of query responses leaking into the input buffer. I suspect this is just an `escape-time` issue, though. Because tmux recently decreased the default time from 500ms to 10ms (see https://github.com/tmux/tmux/commit/2e9d7ebf15615b51b014a12de03b0e5483aadf99). I believe that change would have been introduced in version 3.5. Setting the timeout back to 500ms fixes the issue for me.
claunia commented 2026-01-31 08:10:52 +00:00
Author
Owner
Copy Link

@downhiller commented on GitHub (Mar 26, 2025):

I think I'm experiencing this as well, issue #18714
But I'm not using tmux. 🤔

@downhiller commented on GitHub (Mar 26, 2025): I think I'm experiencing this as well, issue #18714 But I'm not using tmux. 🤔
claunia commented 2026-01-31 08:10:52 +00:00
Author
Owner
Copy Link

@jagardaniel commented on GitHub (Mar 27, 2025):

@j4james Thanks for the info!

I updated my Debian server from Stable to Testing (until Trixie is released) and I'm running into the same problem (tmux version from 3.3a to 3.5a). Configuring tmux with set -sg escape-time 500 like you suggested solved the issue for me as well, so changing back to the old "behavior".

It works fine with other terminals (tried Alacritty on Windows) and I see the same issue if I target another distribution running tmux version 3.5a.

Windows terminal version: 1.22.10731.0

@jagardaniel commented on GitHub (Mar 27, 2025): @j4james Thanks for the info! I updated my Debian server from Stable to Testing (until Trixie is released) and I'm running into the same problem (tmux version from 3.3a to 3.5a). Configuring tmux with `set -sg escape-time 500` like you suggested solved the issue for me as well, so changing back to the old "behavior". It works fine with other terminals (tried Alacritty on Windows) and I see the same issue if I target another distribution running tmux version 3.5a. Windows terminal version: 1.22.10731.0
claunia commented 2026-01-31 08:10:52 +00:00
Author
Owner
Copy Link

@stasjok commented on GitHub (Apr 2, 2025):

For me this started appearing after latest Terminal update (Version: 1.22.10731.0, previously it was 1.21 I think). I have escape-time = 5 in tmux for many years (to make my work in neovim more smooth) and I don't remember ever seeing this. Now it's every time I attach to tmux.

I am so ready to blame win32-openssh already heh

It may be related. My Terminal profiles have Command line like this: ssh server2. When I open terminal window from Terminal, I get this problem. When I open wsl, then ssh to the same server (it's a remote server), it works without issues.

OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2 (I don't know when it was updated last time).

@stasjok commented on GitHub (Apr 2, 2025): For me this started appearing after latest Terminal update (Version: 1.22.10731.0, previously it was 1.21 I think). I have escape-time = 5 in tmux for many years (to make my work in neovim more smooth) and I don't remember ever seeing this. Now it's every time I attach to tmux. > I am so ready to blame win32-openssh already heh It may be related. My Terminal profiles have Command line like this: `ssh server2`. When I open terminal window from Terminal, I get this problem. When I open wsl, then ssh to the same server (it's a remote server), it works without issues. OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2 (I don't know when it was updated last time).
claunia commented 2026-01-31 08:10:53 +00:00
Author
Owner
Copy Link

@jagardaniel commented on GitHub (Apr 2, 2025):

I am so ready to blame win32-openssh already heh

It may be related. My Terminal profiles have Command line like this: ssh server2. When I open terminal window from Terminal, I get this problem. When I open wsl, then ssh to the same server (it's a remote server), it works without issues.

OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2 (I don't know when it was updated last time).

I have two WSL "distributions" installed and they give me different results. I have the same issue if I SSH to a server with tmux 3.5a installed from the one running Ubuntu 24.04 (OpenSSH_9.6p1). But it works if I SSH from the podman-machine-default / Fedora 37 (OpenSSH_8.8p1). And it seems to work if I use Alacritty instead of Windows Terminal with OpenSSH for Windows.

@jagardaniel commented on GitHub (Apr 2, 2025): > > I am so ready to blame win32-openssh already heh > > It may be related. My Terminal profiles have Command line like this: `ssh server2`. When I open terminal window from Terminal, I get this problem. When I open wsl, then ssh to the same server (it's a remote server), it works without issues. > > OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2 (I don't know when it was updated last time). I have two WSL "distributions" installed and they give me different results. I have the same issue if I SSH to a server with tmux 3.5a installed from the one running Ubuntu 24.04 (OpenSSH_9.6p1). But it works if I SSH from the podman-machine-default / Fedora 37 (OpenSSH_8.8p1). And it seems to work if I use Alacritty instead of Windows Terminal with OpenSSH for Windows.
claunia commented 2026-01-31 08:10:53 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Apr 2, 2025):

For me this started appearing after latest Terminal update (Version: 1.22.10731.0, previously it was 1.21 I think).

@stasjok That's understandable. Support for querying OSC 11 was only added in version 1.22, so this problem wouldn't have occurred on an earlier version.

And it seems to work if I use Alacritty instead of Windows Terminal with OpenSSH for Windows.

@jagardaniel Again this is understandable. I believe the Windows version of Alacritty doesn't support OSC 11 queries, unless you've manually updated the conpty dll.

The bottom line is that this is likely just a timeout issue that will depend on the speed of your ssh connection. If you can fix the problem by increasing the tmux escape-time value, I'd suggest you do that.

@j4james commented on GitHub (Apr 2, 2025): > For me this started appearing after latest Terminal update (Version: 1.22.10731.0, previously it was 1.21 I think). @stasjok That's understandable. Support for querying `OSC 11` was only added in version 1.22, so this problem wouldn't have occurred on an earlier version. > And it seems to work if I use Alacritty instead of Windows Terminal with OpenSSH for Windows. @jagardaniel Again this is understandable. I believe the Windows version of Alacritty doesn't support `OSC 11` queries, unless you've manually updated the conpty dll. The bottom line is that this is likely just a timeout issue that will depend on the speed of your ssh connection. If you can fix the problem by increasing the tmux `escape-time` value, I'd suggest you do that.
claunia commented 2026-01-31 08:10:53 +00:00
Author
Owner
Copy Link

@voltagex commented on GitHub (Apr 16, 2025):

Image
I have seen this on machines on the same LAN as well but the 3.3 to 3.5 version difference makes sense.

This was tricky to search for as the text on my end was ^[]11;rgb:11;rgb:0c0c/0c0c/0c0c

@voltagex commented on GitHub (Apr 16, 2025): ![Image](https://github.com/user-attachments/assets/7ced8567-ae78-4b5e-91a6-b1251d627104) I have seen this on machines on the same LAN as well but the 3.3 to 3.5 version difference makes sense. This was tricky to search for as the text on my end was `^[]11;rgb:11;rgb:0c0c/0c0c/0c0c`
claunia commented 2026-01-31 08:10:53 +00:00
Author
Owner
Copy Link

@giuliohome commented on GitHub (Sep 26, 2025):

I am so ready to blame win32-openssh already heh

Indeed, I don’t need escape-time or any other tweaks in my tmux config when I download and use the latest Win32-OpenSSH.

BTW, I’m not sure why the Windows build number is even in the bug form here — other than to waste users’ time.

…But someone’s correlating the two things here 😉

@giuliohome commented on GitHub (Sep 26, 2025): > I am so ready to blame win32-openssh already heh Indeed, I don’t need `escape-time` or any other tweaks in my tmux config when I download and use the latest Win32-OpenSSH. BTW, I’m not sure why the Windows build number is even in the bug form here — other than to waste users’ time. …But someone’s correlating the two things [here](https://github.com/PowerShell/Win32-OpenSSH/issues/2053#issuecomment-2176572125) 😉
claunia commented 2026-01-31 08:10:54 +00:00
Author
Owner
Copy Link

@giuliohome commented on GitHub (Sep 27, 2025):

BTW, I’m not sure why the Windows build number is even in the bug form here — other than to waste users’ time.

😆 Except that on Win10 (build 10.0.19045.0), even with the latest WT (1.24.250925002-preview) and the latest SSH (OpenSSH_for_Windows_9.8p2 Win32-OpenSSH-GitHub, LibreSSL 4.0.0), I still need one tweak:

set -as terminal-overrides '*:smcup@:rmcup@'

…to disable the alternate screen as a workaround for this issue (without the workaround, on my Win10 end, the text looked like ^[[?61;4;6;7;14;21;22;23;24;28;32;42;52c^[[>0;10;1cgiulio@myhome:~$ 61;4;6;7;14;21;22;23;24;28;32;42;52c0;10;1c).

On Windows 10 (replicated also on 10.0.19045.3803 fresh install on VirtualBox), Windows Terminal mishandles DA responses in alternate-screen mode over a pseudo-terminal, producing visible escape sequences; this is a WT issue, not a tmux or SSH bug.

@giuliohome commented on GitHub (Sep 27, 2025): > BTW, I’m not sure why the Windows build number is even in the bug form here — other than to waste users’ time. 😆 Except that on **Win10 (build 10.0.19045.0)**, even with the latest WT (1.24.250925002-preview) and the latest SSH (OpenSSH_for_Windows_9.8p2 Win32-OpenSSH-GitHub, LibreSSL 4.0.0), I still need one tweak: ``` set -as terminal-overrides '*:smcup@:rmcup@' ``` …to disable the alternate screen as a workaround for this issue (without the workaround, on my Win10 end, the text looked like `^[[?61;4;6;7;14;21;22;23;24;28;32;42;52c^[[>0;10;1cgiulio@myhome:~$ 61;4;6;7;14;21;22;23;24;28;32;42;52c0;10;1c`). On Windows 10 (replicated also on 10.0.19045.3803 fresh install on VirtualBox), Windows Terminal mishandles DA responses in alternate-screen mode over a pseudo-terminal, producing visible escape sequences; this is a WT issue, not a tmux or SSH bug.
claunia commented 2026-01-31 08:10:54 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 27, 2025):

I’m not sure why the Windows build number is even in the bug form here — other than to waste users’ time.

It may surprise you to learn that people report bugs outside of the console hosting infrastructure.

@DHowett commented on GitHub (Sep 27, 2025): > I’m not sure why the Windows build number is even in the bug form here — other than to waste users’ time. It may surprise you to learn that people report bugs outside of the console hosting infrastructure.
claunia commented 2026-01-31 08:10:54 +00:00
Author
Owner
Copy Link

@giuliohome commented on GitHub (Sep 27, 2025):

As I have practically demonstrated, even after reinstalling Windows 10 from scratch from the .iso, there must be a bug at some driver or OS level that the WT/ConPTY stack is eventually leveraging when SSH-ing to tmux. Hence, I doubt you can find a real fix here, aside from the workaround I have already found myself. But let's see if I am wrong and a fix is found that shows something different than what I suspect.

@giuliohome commented on GitHub (Sep 27, 2025): As I have practically demonstrated, even after reinstalling Windows 10 from scratch from the .iso, there must be a bug at some driver or OS level that the WT/ConPTY stack is eventually leveraging when SSH-ing to tmux. Hence, I doubt you can find a real fix here, aside from the workaround I have already found myself. But let's see if I am wrong and a fix is found that shows something different than what I suspect.
claunia commented 2026-01-31 08:10:54 +00:00
Author
Owner
Copy Link

@giuliohome commented on GitHub (Sep 28, 2025):

Also, you are hiding the truth by labeling it as abuse because you can't accept the truth. That is a typical problem with Microsoft members and repositories that are open sourced only for faking transparency

@giuliohome commented on GitHub (Sep 28, 2025): Also, you are hiding the truth by labeling it as abuse because you can't accept the truth. That is a typical problem with Microsoft members and repositories that are open sourced only for faking transparency
claunia commented 2026-01-31 08:10:55 +00:00
Author
Owner
Copy Link

@giuliohome commented on GitHub (Sep 28, 2025):

  1. Labeling my technical analysis as "abuse" - That's completely inappropriate. My original message was factual, evidence-based, and respectful

  2. When maintainers use "abuse" labels to silence technical disagreement backed by evidence, it does suggest they're more interested in protecting their narrative than solving the actual problem.

  3. The fact that they can't technically refute my evidence (fresh OS install proving OS dependency) but resort to moderation abuse instead speaks volumes about the validity of my technical analysis.

@giuliohome commented on GitHub (Sep 28, 2025): 1. **Labeling my technical analysis as "abuse"** - That's completely inappropriate. My original message was factual, evidence-based, and respectful 2. When maintainers use "abuse" labels **to silence technical disagreement backed by evidence**, it does suggest they're more interested in protecting their narrative than solving the actual problem. 3. The fact that they can't technically refute my evidence (**fresh OS install proving OS dependency**) but resort to moderation abuse instead speaks volumes about the validity of my technical analysis.
claunia commented 2026-01-31 08:10:55 +00:00
Author
Owner
Copy Link

@voltagex commented on GitHub (Sep 28, 2025):

hey @giuliohome do you think posting like this is going to help resolve the situation or inflame it more?

@voltagex commented on GitHub (Sep 28, 2025): hey @giuliohome do you think posting like this is going to help resolve the situation or inflame it more?
claunia commented 2026-01-31 08:10:55 +00:00
Author
Owner
Copy Link

@giuliohome commented on GitHub (Sep 28, 2025):

@voltagex
The situation was already inflamed when my respectful, evidence-based technical analysis was inappropriately labeled as 'abuse.' I provided concrete evidence (fresh Windows 10 install) that contradicts the 'OS-independent' claims, and instead of addressing that evidence, it was silenced through moderation abuse. The real question is why legitimate technical disagreement backed by empirical data is being treated as 'abuse.'

@giuliohome commented on GitHub (Sep 28, 2025): @voltagex The situation was already inflamed when my respectful, evidence-based technical analysis was inappropriately labeled as 'abuse.' I provided concrete evidence (fresh Windows 10 install) that contradicts the 'OS-independent' claims, and instead of addressing that evidence, it was silenced through moderation abuse. The real question is why legitimate technical disagreement backed by empirical data is being treated as 'abuse.'
claunia commented 2026-01-31 08:10:55 +00:00
Author
Owner
Copy Link

@voltagex commented on GitHub (Sep 28, 2025):

Is it worth answering that question versus de-escalating?

Do you think the current line of questioning will lead to satisfactory answers?

@voltagex commented on GitHub (Sep 28, 2025): Is it worth answering that question versus de-escalating? Do you think the current line of questioning will lead to satisfactory answers?
claunia commented 2026-01-31 08:10:56 +00:00
Author
Owner
Copy Link

@voltagex commented on GitHub (Sep 28, 2025):

@giuliohome if you still have your Windows 10 test set up, could you try ssh.exe from https://github.com/PowerShell/Win32-OpenSSH/releases/download/v9.8.3.0p2-Preview/OpenSSH-Win64.zip?

@voltagex commented on GitHub (Sep 28, 2025): @giuliohome if you still have your Windows 10 test set up, could you try ssh.exe from https://github.com/PowerShell/Win32-OpenSSH/releases/download/v9.8.3.0p2-Preview/OpenSSH-Win64.zip?
claunia commented 2026-01-31 08:10:56 +00:00
Author
Owner
Copy Link

@giuliohome commented on GitHub (Sep 28, 2025):

Will easily rebuild the VM from the iso and will try that in a few hours but not immediately. Thank you

@giuliohome commented on GitHub (Sep 28, 2025): Will easily rebuild the VM from the iso and will try that in a few hours but not immediately. Thank you
claunia commented 2026-01-31 08:10:57 +00:00
Author
Owner
Copy Link

@giuliohome commented on GitHub (Sep 28, 2025):

Ops, actually it is the exact same zip I used in my test, already done, no need to repeat it.

@giuliohome commented on GitHub (Sep 28, 2025): Ops, actually it is the exact same zip I used in my test, already done, no need to repeat it.
claunia commented 2026-01-31 08:10:57 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Sep 28, 2025):

@microsoft A couple of naive questions (forgive me, I'm confused due to the mass of open issues in different places about the same behavior). Am I correct in understanding that the conhost.exe supplied with the system is an outdated instance of OpenConsole.exe? Am I correct in understanding (based on the output from https://github.com/microsoft/edit/issues/109#issuecomment-3241919847) that this issue has long been fixed, but there is a policy prohibition on backporting changes to Windows 10 (should we wait until free Windows 10 support ends)?

@o-sdn-o commented on GitHub (Sep 28, 2025): @microsoft A couple of naive questions (forgive me, I'm confused due to the mass of open issues in different places about the same behavior). Am I correct in understanding that the conhost.exe supplied with the system is an outdated instance of OpenConsole.exe? Am I correct in understanding (based on the output from https://github.com/microsoft/edit/issues/109#issuecomment-3241919847) that this issue has long been fixed, but there is a policy prohibition on backporting changes to Windows 10 (should we wait until free Windows 10 support ends)?
claunia commented 2026-01-31 08:10:57 +00:00
Author
Owner
Copy Link

@giuliohome commented on GitHub (Sep 28, 2025):

@microsoft Could you clarify why a comment of mine was removed?

Image

In that comment I simply noted that I’m aware OpenConsole.exe is included in this repository’s releases, and that the issue appears only when WindowsTerminal.exe is running and seems to be OS-dependent (it reproduces on Windows 10 but not on Windows 11).

@giuliohome commented on GitHub (Sep 28, 2025): @microsoft Could you clarify why a comment of mine was removed? <img width="519" height="67" alt="Image" src="https://github.com/user-attachments/assets/ac6a86ba-1124-4484-9f9b-ff179d470dc4" /> In that comment I simply noted that I’m aware `OpenConsole.exe` is included in this repository’s releases, and that the issue appears only when `WindowsTerminal.exe` is running and seems to be OS-dependent (it reproduces on Windows 10 but not on Windows 11).
claunia commented 2026-01-31 08:10:57 +00:00
Author
Owner
Copy Link

@splooge commented on GitHub (Oct 11, 2025):

Just wanted to confirm that changing the following in tmux.conf:

set-option -sg escape-time 10

to

set-option -sg escape-time 40

Fixed the issue for me.

@splooge commented on GitHub (Oct 11, 2025): Just wanted to confirm that changing the following in tmux.conf: `set-option -sg escape-time 10` to `set-option -sg escape-time 40` Fixed the issue for me.
claunia commented 2026-01-31 08:10:58 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 6, 2026):

This should be fixed as of Win32-OpenSSH with https://github.com/PowerShell/openssh-portable/pull/806

@DHowett commented on GitHub (Jan 6, 2026): This should be fixed as of Win32-OpenSSH with https://github.com/PowerShell/openssh-portable/pull/806
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-VT Issue-Bug Needs-Tag-Fix Product-Terminal
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#22359
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?