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

"Open Windows Terminal here" does not continue to work for subsequent tabs, panes #12256

New Issue
Closed
opened 2026-01-31 03:10:29 +00:00 by claunia · 14 comments
claunia commented 2026-01-31 03:10:29 +00:00
Owner
Copy Link

Originally created by @TigerBeanst on GitHub (Jan 29, 2021).

Environment

Windows build number: 10.0.19042.0
Windows Terminal version (if applicable): 1.5.10271.0

Any other software?

Steps to reproduce

  1. Click "Open Windows Terminal here" in directory
  2. Click WSL or CMD (anything that different than the default tab)
    image

Else, I have been add startingDirectory in setting:

"profiles":
    {
        "defaults":
        {
            "startingDirectory" : "."
            // Put settings here that you want to apply to all profiles.
        },

Expected behavior

For example, I click "Open Windows Terminal here" in D:\Games.
What I think it should be:
image
image
image

Actual behavior

My default tab is Powershell7, it works well:
image
But if I switch to WSL or CMD:
image
image

the path goes to C:\Windows\system32.

Other

I now use this for me:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\Background\shell\wt]
@="Open in Windows Terminal here"
"Icon"="%USERPROFILE%\\AppData\\Local\\terminal\\wt_32.ico"

[HKEY_CLASSES_ROOT\Directory\Background\shell\wt\command]
@="C:\\Users\\hjthjthjt\\AppData\\Local\\Microsoft\\WindowsApps\\wt.exe"

It works as my expect. But the new feature "Open Windows Terminal here" does not.

Originally created by @TigerBeanst on GitHub (Jan 29, 2021). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none Windows build number: 10.0.19042.0 Windows Terminal version (if applicable): 1.5.10271.0 Any other software? ``` # Steps to reproduce 1. Click "Open Windows Terminal here" in directory 2. Click WSL or CMD (anything that different than the default tab) ![image](https://user-images.githubusercontent.com/3889846/106230766-36f3df80-622b-11eb-96df-28296e953e04.png) Else, I have been add `startingDirectory` in setting: ``` "profiles": { "defaults": { "startingDirectory" : "." // Put settings here that you want to apply to all profiles. }, ``` <!-- A description of how to trigger this bug. --> # Expected behavior For example, I click "Open Windows Terminal here" in `D:\Games`. What I think it should be: ![image](https://user-images.githubusercontent.com/3889846/106230971-9a7e0d00-622b-11eb-8d60-3be1adff88d7.png) ![image](https://user-images.githubusercontent.com/3889846/106230985-9eaa2a80-622b-11eb-920b-ec7006aa9f12.png) ![image](https://user-images.githubusercontent.com/3889846/106231001-a36ede80-622b-11eb-9187-67cebf01f19a.png) <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> # Actual behavior <!-- What's actually happening? --> My default tab is Powershell7, it works well: ![image](https://user-images.githubusercontent.com/3889846/106230866-67d41480-622b-11eb-9e62-502358525f3e.png) But if I switch to WSL or CMD: ![image](https://user-images.githubusercontent.com/3889846/106230908-74f10380-622b-11eb-89be-34158d98da57.png) ![image](https://user-images.githubusercontent.com/3889846/106230916-7ae6e480-622b-11eb-8587-ab7a026f6029.png) the path goes to `C:\Windows\system32`. # Other I now use this for me: ``` Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\Directory\Background\shell\wt] @="Open in Windows Terminal here" "Icon"="%USERPROFILE%\\AppData\\Local\\terminal\\wt_32.ico" [HKEY_CLASSES_ROOT\Directory\Background\shell\wt\command] @="C:\\Users\\hjthjthjt\\AppData\\Local\\Microsoft\\WindowsApps\\wt.exe" ``` It works as my expect. But the new feature "Open Windows Terminal here" does not.
claunia commented 2026-01-31 03:10:30 +00:00
Author
Owner
Copy Link

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

Hmm. Looks like we're only applying the "open in Windows Terminal" to the first tab that's created. So wt.exe's CWD is still c:\windows\system32, meaning subsequent tabs opened with . as a startingDirectory would use c:\windows\system32.

I think there's another issue floating around here tracking something similar, but I for the life of me can't find it.

For this one, maybe we shouldn't ONLY be doing wt -d <the path from explorer> - maybe there's some way to set the CWD for the child process itself? I'd assume that wt would inherit it from it's parent explorer.exe, but maybe we're doing something wrong here.

@zadjii-msft commented on GitHub (Jan 29, 2021): Hmm. Looks like we're only applying the "open in Windows Terminal" to the _first_ tab that's created. So `wt.exe`'s CWD is still `c:\windows\system32`, meaning subsequent tabs opened with `.` as a startingDirectory would use `c:\windows\system32`. I think there's another issue floating around here tracking something similar, but I for the life of me can't find it. For this one, maybe we shouldn't ONLY be doing `wt -d <the path from explorer>` - maybe there's some way to set the CWD for the child process itself? I'd assume that `wt` would inherit it from it's parent `explorer.exe`, but maybe we're doing something wrong here.
claunia commented 2026-01-31 03:10:31 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Jan 29, 2021):

What is the expected behaviour if "Open Windows Terminal here" in some future version opens a new tab in an existing Windows Terminal window (related to https://github.com/microsoft/terminal/issues/4472 but not necessarily using wt.exe), and the user then uses the profile menu to start another session with "startingDirectory": "." in that window?

I think Windows Terminal should resolve "startingDirectory": "." from the current directory of the active session of the window whose profile menu the user used. The current directory of each session could be changed with OSC 7 (https://github.com/microsoft/terminal/issues/3158) and would default to the starting directory of the session, such as the directory received from "Open Windows Terminal here".

@KalleOlaviNiemitalo commented on GitHub (Jan 29, 2021): What is the expected behaviour if "Open Windows Terminal here" in some future version opens a new tab in an existing Windows Terminal window (related to <https://github.com/microsoft/terminal/issues/4472> but not necessarily using `wt.exe`), and the user then uses the profile menu to start another session with `"startingDirectory": "."` in that window? I think Windows Terminal should resolve `"startingDirectory": "."` from the current directory of the *active session of the window* whose profile menu the user used. The current directory of each session could be changed with OSC 7 (<https://github.com/microsoft/terminal/issues/3158>) and would default to the starting directory of the session, such as the directory received from "Open Windows Terminal here".
claunia commented 2026-01-31 03:10:31 +00:00
Author
Owner
Copy Link

@patricknelson commented on GitHub (Mar 19, 2021):

My workaround to address this (to ensure that new panes/tabs open with the same starting directory) is to do the following:

  1. Use BroJenuel/Explorer-Context-Menu-Integration-for-windows-terminal for right-click integration instead.
  2. Remove the duplicate entry using the registry fix documented here: https://github.com/microsoft/terminal/issues/7008#issuecomment-662621638

Demo:

2021-03-18_18-34-07

@patricknelson commented on GitHub (Mar 19, 2021): My workaround to address this (to ensure that new panes/tabs open with the same starting directory) is to do the following: 1. Use [BroJenuel/Explorer-Context-Menu-Integration-for-windows-terminal](https://github.com/BroJenuel/Explorer-Context-Menu-Integration-for-windows-terminal) for right-click integration instead. 2. Remove the duplicate entry using the registry fix documented here: https://github.com/microsoft/terminal/issues/7008#issuecomment-662621638 **Demo:** ![2021-03-18_18-34-07](https://user-images.githubusercontent.com/4269377/111719209-a55f2200-8818-11eb-8bdb-228eb55f8fd1.gif)
claunia commented 2026-01-31 03:10:31 +00:00
Author
Owner
Copy Link

@Dominiquini commented on GitHub (Apr 15, 2021):

The last version of Windows Terminal (1.7.1033.0) have the option "Use parent process directory", that I should do what I wanted, but it is not working! Only the first profile open in the directory I choose. But when I create a new profile in a new tab, it opens in the "C:\Windows\system32" directory.

@Dominiquini commented on GitHub (Apr 15, 2021): The last version of Windows Terminal (1.7.1033.0) have the option "Use parent process directory", that I should do what I wanted, but it is not working! Only the first profile open in the directory I choose. But when I create a new profile in a new tab, it opens in the "C:\Windows\system32\" directory.
claunia commented 2026-01-31 03:10:31 +00:00
Author
Owner
Copy Link

@rafrafek commented on GitHub (Apr 29, 2021):

For me it is not only not working, but also breaks Git Bash:

  • history of commands is not saved,
  • settings like .inputrc are not loaded,
  • some programs like ssh are totally broken.

This is my output from Windows Terminal, from Git Bash, when opened via "Open in Windows Terminal" context menu, then new tab:

$ ssh foo
vdollar_percent_expand: unknown key %H
percent_dollar_expand: failed

When Windows Terminal is opened via Menu Start everything works perfectly.

@rafrafek commented on GitHub (Apr 29, 2021): For me it is not only not working, but also **breaks Git Bash**: - history of commands is not saved, - settings like .inputrc are not loaded, - some programs like ssh are totally broken. This is my output from Windows Terminal, from Git Bash, when opened via "Open in Windows Terminal" context menu, then new tab: ``` $ ssh foo vdollar_percent_expand: unknown key %H percent_dollar_expand: failed ``` When Windows Terminal is opened via Menu Start everything works perfectly.
claunia commented 2026-01-31 03:10:31 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 29, 2021):

@rafrafek That's certainly unexpected, but very weird that your git bash profile would behave so differently if the starting directory was C:\windows\system32 instead of whatever directory you clicked on. Could you share the contents of your git bash profile in settings.json?

@zadjii-msft commented on GitHub (Apr 29, 2021): @rafrafek That's certainly unexpected, but very weird that your git bash profile would behave so differently if the starting directory was `C:\windows\system32` instead of whatever directory you clicked on. Could you share the contents of your git bash profile in `settings.json`?
claunia commented 2026-01-31 03:10:32 +00:00
Author
Owner
Copy Link

@rafrafek commented on GitHub (Apr 29, 2021):

@zadjii-msft Yes, sure. It looks like this:

...
"defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
    "profiles": 
    {
        "defaults": 
        {
            "useAcrylic": false
        },
        "list": 
        [
            {
                "commandline": "%PROGRAMFILES%/Git/usr/bin/bash.exe -i -l",
                "guid": "{00000000-0000-0000-ba54-000000000002}",
                "icon": "%PROGRAMFILES%/Git/mingw64/share/git/git-for-windows.ico",
                "name": "Bash",
                "startingDirectory": "%USERPROFILE%"
            },
            {
                "commandline": "powershell.exe",
                "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
                "hidden": false,
                "name": "Windows PowerShell"
            },
...
@rafrafek commented on GitHub (Apr 29, 2021): @zadjii-msft Yes, sure. It looks like this: ``` ... "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "profiles": { "defaults": { "useAcrylic": false }, "list": [ { "commandline": "%PROGRAMFILES%/Git/usr/bin/bash.exe -i -l", "guid": "{00000000-0000-0000-ba54-000000000002}", "icon": "%PROGRAMFILES%/Git/mingw64/share/git/git-for-windows.ico", "name": "Bash", "startingDirectory": "%USERPROFILE%" }, { "commandline": "powershell.exe", "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "hidden": false, "name": "Windows PowerShell" }, ... ```
claunia commented 2026-01-31 03:10:32 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Apr 29, 2021):

vdollar_percent_expand: unknown key %H is a message from OpenSSH.

I wonder if the %H is part of something like %HOMEDRIVE% in the value of an environment variable. @rafrafek, which version of Windows Terminal are you using? Windows Terminal Preview suffers from https://github.com/microsoft/terminal/issues/9741, which is known to leave % signs in the value of the PSModulePath environment variable and might possibly also affect some environment variable that ssh examines.

@KalleOlaviNiemitalo commented on GitHub (Apr 29, 2021): `vdollar_percent_expand: unknown key %H` is a [message from OpenSSH](https://github.com/openssh/openssh-portable/blob/2dc328023f60212cd29504fc05d849133ae47355/misc.c#L1249). I wonder if the `%H` is part of something like `%HOMEDRIVE%` in the value of an environment variable. @rafrafek, which version of Windows Terminal are you using? Windows Terminal Preview suffers from <https://github.com/microsoft/terminal/issues/9741>, which is known to leave `%` signs in the value of the `PSModulePath` environment variable and might possibly also affect some environment variable that `ssh` examines.
claunia commented 2026-01-31 03:10:32 +00:00
Author
Owner
Copy Link

@rafrafek commented on GitHub (Apr 29, 2021):

@KalleOlaviNiemitalo It is 1.7.1033.0 installed from GitHub releases.

@rafrafek commented on GitHub (Apr 29, 2021): @KalleOlaviNiemitalo It is 1.7.1033.0 installed from GitHub releases.
claunia commented 2026-01-31 03:10:32 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Apr 29, 2021):

@rafrafek, in the Git Bash session in which ssh does not work, does the value of the HOME environment variable contain any percent signs? If it does, that would explain why Bash does not find .inputrc.

@KalleOlaviNiemitalo commented on GitHub (Apr 29, 2021): @rafrafek, in the Git Bash session in which `ssh` does not work, does the value of the `HOME` environment variable contain any percent signs? If it does, that would explain why Bash does not find `.inputrc`.
claunia commented 2026-01-31 03:10:32 +00:00
Author
Owner
Copy Link

@rafrafek commented on GitHub (Apr 29, 2021):

@KalleOlaviNiemitalo Yes!
Bad session opened via "Open in Windows Terminal":

$ echo $HOME
/c/Users/xxx/%HOMEDRIVE%%HOMEPATH%

Good session opened via Menu Start:

$ echo $HOME
/c/Users/xxx

Where xxx is my login.

@rafrafek commented on GitHub (Apr 29, 2021): @KalleOlaviNiemitalo Yes! Bad session opened via "Open in Windows Terminal": ``` $ echo $HOME /c/Users/xxx/%HOMEDRIVE%%HOMEPATH% ``` Good session opened via Menu Start: ``` $ echo $HOME /c/Users/xxx ``` Where `xxx` is my login.
claunia commented 2026-01-31 03:10:33 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Apr 29, 2021):

OK, I can reproduce on Windows 10 build 19042.928 if I define "HOME" = REG_EXPAND_SZ "%HOMEDRIVE%%HOMEPATH%" as a user environment variable like so:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Environment]
"HOME"=hex(2):25,00,48,00,4f,00,4d,00,45,00,44,00,52,00,49,00,56,00,45,00,25,\
  00,25,00,48,00,4f,00,4d,00,45,00,50,00,41,00,54,00,48,00,25,00,00,00
  • Start Windows Terminal 1.7.1033.0 from the Start menu. It opens a PowerShell session. $env:HOME has the expanded value. Open a Command Prompt session in another tab. set HOME displays the expanded value.
  • Start Windows Terminal 1.7.1033.0 from the shell extension (window background). It opens a PowerShell session. $env:HOME is literally %HOMEDRIVE%%HOMEPATH% unexpanded. Open a Command Prompt session in another tab. set HOME displays HOME=%HOMEDRIVE%%HOMEPATH%.

The incorrect value of the environment variable thus shows up both in the original tab and the subsequently opened tab. Also, this happens even if settings.json does not specify "startingDirectory" at all. Therefore, I think the problem with ssh is distinct from this https://github.com/microsoft/terminal/issues/8933.

Process Monitor shows that the wt.exe process gets the unexpanded HOME=%HOMEDRIVE%%HOMEPATH% in its environment block when the shell extension starts it. The shell extension is loaded to a DllHost.exe process, which likewise gets the unexpanded HOME=%HOMEDRIVE%%HOMEPATH% when svchost.exe starts it.

According to https://github.com/microsoft/terminal/issues/9741#issuecomment-815420501, Windows loads HOMEDRIVE and HOMEPATH only after it has already loaded REG_EXPAND_SZ values from "HKU\<SID string>\Environment". However, the "Environment Variables" dialog box of Windows displays the expanded value if I configure HOME as %HOMEDRIVE%%HOMEPATH%. Because of that, I think this is a bug in Windows, although Windows Terminal could be changed to work around it.

@KalleOlaviNiemitalo commented on GitHub (Apr 29, 2021): OK, I can reproduce on Windows 10 build 19042.928 if I define "HOME" = REG_EXPAND_SZ "%HOMEDRIVE%%HOMEPATH%" as a user environment variable like so: ``` Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Environment] "HOME"=hex(2):25,00,48,00,4f,00,4d,00,45,00,44,00,52,00,49,00,56,00,45,00,25,\ 00,25,00,48,00,4f,00,4d,00,45,00,50,00,41,00,54,00,48,00,25,00,00,00 ``` * Start Windows Terminal 1.7.1033.0 from the Start menu. It opens a PowerShell session. `$env:HOME` has the expanded value. Open a Command Prompt session in another tab. `set HOME` displays the expanded value. * Start Windows Terminal 1.7.1033.0 from the shell extension (window background). It opens a PowerShell session. `$env:HOME` is literally `%HOMEDRIVE%%HOMEPATH%` unexpanded. Open a Command Prompt session in another tab. `set HOME` displays `HOME=%HOMEDRIVE%%HOMEPATH%`. The incorrect value of the environment variable thus shows up both in the original tab and the subsequently opened tab. Also, this happens even if settings.json does not specify "startingDirectory" at all. Therefore, I think the problem with `ssh` is distinct from this <https://github.com/microsoft/terminal/issues/8933>. Process Monitor shows that the `wt.exe` process gets the unexpanded `HOME=%HOMEDRIVE%%HOMEPATH%` in its environment block when the shell extension starts it. The shell extension is loaded to a `DllHost.exe` process, which likewise gets the unexpanded `HOME=%HOMEDRIVE%%HOMEPATH%` when `svchost.exe` starts it. According to <https://github.com/microsoft/terminal/issues/9741#issuecomment-815420501>, Windows loads `HOMEDRIVE` and `HOMEPATH` only after it has already loaded `REG_EXPAND_SZ` values from `"HKU\<SID string>\Environment"`. However, the "Environment Variables" dialog box of Windows displays the expanded value if I configure `HOME` as `%HOMEDRIVE%%HOMEPATH%`. Because of that, I think this is a bug in Windows, although Windows Terminal could be changed to work around it.
claunia commented 2026-01-31 03:10:33 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 14, 2021):

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

Handy links:

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

@ghost commented on GitHub (Jul 14, 2021):

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

Handy links:

@ghost commented on GitHub (Jul 14, 2021): :tada:This issue was addressed in #10546, which has now been successfully released as `Windows Terminal Preview v1.10.1933.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.10.1933.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
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-ShellExtension Help Wanted 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#12256
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?