starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Opening Windows Terminal in current directory from right-click folder context menu (the ubuntu.exe bug) #17316

New Issue
Open
opened 2026-01-31 05:38:45 +00:00 by claunia · 40 comments
claunia commented 2026-01-31 05:38:45 +00:00
Owner
Copy Link

Originally created by @marcodiiga on GitHub (Apr 21, 2022).

Description of the new feature/enhancement

I couldn't find a way to open up wt.exe in a linux profile (e.g. Ubuntu) via right-click in the context menu that pops up in explorer by setting the current working directory to whatever I was browsing before.

To rephrase: I added some HKCR\Directory\Background\shell\wt\command key with wt.exe -d "%V" so that I can Shift+RightClick in a folder in explorer.exe and have a Open in Windows Terminal with Linux item in the context menu. Windows Terminal opens but the starting directory, no matter what I set the profile startingDirectory field in the JSON to, is always set to my home directory. It would be nice if wt.exe -d "C:\\" or whatever actually opened, for the linux profile, in /mnt/c as starting directory.

Originally created by @marcodiiga on GitHub (Apr 21, 2022). # Description of the new feature/enhancement I couldn't find a way to open up `wt.exe` in a linux profile (e.g. `Ubuntu`) via right-click in the context menu that pops up in explorer by setting the current working directory to whatever I was browsing before. To rephrase: I added some `HKCR\Directory\Background\shell\wt\command` key with `wt.exe -d "%V"` so that I can Shift+RightClick in a folder in explorer.exe and have a `Open in Windows Terminal with Linux` item in the context menu. Windows Terminal opens but the starting directory, no matter what I set the profile `startingDirectory` field in the JSON to, is always set to my home directory. It would be nice if `wt.exe -d "C:\\"` or whatever actually opened, for the linux profile, in `/mnt/c` as starting directory.
claunia commented 2026-01-31 05:38:46 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 21, 2022):

What version are you on? Could you share your settings.json file?

I'm mildly worried that our ~ auto promotion may have accidentally interfered with the ability to use the explorer context menu entry with a WSL profile 😬

aside: Is there a reason you're not just using the explorer context menu entry that the Terminal creates itself when you install it/?

@zadjii-msft commented on GitHub (Apr 21, 2022): What version are you on? Could you share your [settings.json file](https://github.com/microsoft/terminal/wiki/Frequently-Asked-Questions-(FAQ)#where-can-i-find-the-settings-file)? I'm mildly worried that our `~` auto promotion may have accidentally interfered with the ability to use the explorer context menu entry with a WSL profile 😬 aside: Is there a reason you're not just using the explorer context menu entry that the Terminal creates itself when you install it/?
claunia commented 2026-01-31 05:38:47 +00:00
Author
Owner
Copy Link

@marcodiiga commented on GitHub (Apr 21, 2022):

Sure, here's my settings.json:

{
    "$help": "https://aka.ms/terminal-documentation",
    "$schema": "https://aka.ms/terminal-profiles-schema",
    "actions":
    [
        {
            "command":
            {
                "action": "copy",
                "singleLine": false
            },
            "keys": "ctrl+c"
        },
        {
            "command": "paste",
            "keys": "ctrl+v"
        },
        {
            "command": "find",
            "keys": "ctrl+shift+f"
        },
        {
            "command":
            {
                "action": "splitPane",
                "split": "auto",
                "splitMode": "duplicate"
            },
            "keys": "alt+shift+d"
        }
    ],
    "copyFormatting": "none",
    "copyOnSelect": false,
    "defaultProfile": "{51855cb2-8cce-5362-8f54-464b92b32386}",
    "language": "en-US",
    "profiles":
    {
        "defaults": {},
        "list":
        [
            {
                "commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
                "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
                "hidden": false,
                "name": "Windows PowerShell"
            },
            {
                "commandline": "%SystemRoot%\\System32\\cmd.exe",
                "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
                "hidden": false,
                "name": "Prompt dei comandi"
            },
            {
                "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
                "hidden": true,
                "name": "Ubuntu",
                "source": "Windows.Terminal.Wsl",
                "startingDirectory": "%USERPROFILE%"
            },
            {
                "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
                "hidden": false,
                "name": "Azure Cloud Shell",
                "source": "Windows.Terminal.Azure"
            },
            {
                "guid": "{5b849eef-e172-55b9-8019-ef031bec368c}",
                "hidden": false,
                "name": "Developer Command Prompt for VS 2022",
                "source": "Windows.Terminal.VisualStudio"
            },
            {
                "guid": "{8c6e956b-317a-5194-b80e-c5281032870f}",
                "hidden": false,
                "name": "Developer PowerShell for VS 2022",
                "source": "Windows.Terminal.VisualStudio"
            },
            {
                "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}",
                "hidden": false,
                "name": "Ubuntu",
                "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc",
                "startingDirectory": "%USERPROFILE%"
            }
        ]
    },
    "schemes":
    [
       ... unimportant I guess...
    ]
}

For the second question: the context menu entry created at install time doesn't set the starting directory to the current one I was browsing while I clicked with Shift+RightClick either, seems to work with the WSL profile, not with the other Ubuntu profile.

@marcodiiga commented on GitHub (Apr 21, 2022): Sure, here's my settings.json: ```json { "$help": "https://aka.ms/terminal-documentation", "$schema": "https://aka.ms/terminal-profiles-schema", "actions": [ { "command": { "action": "copy", "singleLine": false }, "keys": "ctrl+c" }, { "command": "paste", "keys": "ctrl+v" }, { "command": "find", "keys": "ctrl+shift+f" }, { "command": { "action": "splitPane", "split": "auto", "splitMode": "duplicate" }, "keys": "alt+shift+d" } ], "copyFormatting": "none", "copyOnSelect": false, "defaultProfile": "{51855cb2-8cce-5362-8f54-464b92b32386}", "language": "en-US", "profiles": { "defaults": {}, "list": [ { "commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe", "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "hidden": false, "name": "Windows PowerShell" }, { "commandline": "%SystemRoot%\\System32\\cmd.exe", "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}", "hidden": false, "name": "Prompt dei comandi" }, { "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}", "hidden": true, "name": "Ubuntu", "source": "Windows.Terminal.Wsl", "startingDirectory": "%USERPROFILE%" }, { "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}", "hidden": false, "name": "Azure Cloud Shell", "source": "Windows.Terminal.Azure" }, { "guid": "{5b849eef-e172-55b9-8019-ef031bec368c}", "hidden": false, "name": "Developer Command Prompt for VS 2022", "source": "Windows.Terminal.VisualStudio" }, { "guid": "{8c6e956b-317a-5194-b80e-c5281032870f}", "hidden": false, "name": "Developer PowerShell for VS 2022", "source": "Windows.Terminal.VisualStudio" }, { "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}", "hidden": false, "name": "Ubuntu", "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc", "startingDirectory": "%USERPROFILE%" } ] }, "schemes": [ ... unimportant I guess... ] } ``` For the second question: the context menu entry created at install time doesn't set the starting directory to the current one I was browsing while I clicked with Shift+RightClick either, seems to work with the WSL profile, not with the other Ubuntu profile.
claunia commented 2026-01-31 05:38:47 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 21, 2022):

            {
                "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
                "hidden": true,
                "name": "Ubuntu",
                "source": "Windows.Terminal.Wsl",
                "startingDirectory": "%USERPROFILE%"
            },
			// ...
            {
                "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}",
                "hidden": false,
                "name": "Ubuntu",
                "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc",
                "startingDirectory": "%USERPROFILE%"
            }

Interesting - canonical is shipping their own profile, but not one layered with the existing profile. Curious....

@zadjii-msft commented on GitHub (Apr 21, 2022): ```jsonc { "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}", "hidden": true, "name": "Ubuntu", "source": "Windows.Terminal.Wsl", "startingDirectory": "%USERPROFILE%" }, // ... { "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}", "hidden": false, "name": "Ubuntu", "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc", "startingDirectory": "%USERPROFILE%" } ``` Interesting - canonical is shipping their own profile, but not one layered with the existing profile. Curious....
claunia commented 2026-01-31 05:38:47 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 21, 2022):

Interesting. I really can't get this to repro... Is this always affecting a specific path? I know there have been troubles with doing this in the root of a drive before (e.g. c:\, or D:\), but child directories seem to work fine.

Which OS version and Terminal version are you on/? IIRC there were some os-side issues with Directory/Background entries in the past

@zadjii-msft commented on GitHub (Apr 21, 2022): Interesting. I really can't get this to repro... Is this always affecting a specific path? I know there have been troubles with doing this in the root of a drive before (e.g. `c:\`, or `D:\`), but child directories seem to work fine. Which OS version and Terminal version are you on/? IIRC there were some os-side issues with Directory/Background entries in the past
claunia commented 2026-01-31 05:38:47 +00:00
Author
Owner
Copy Link

@marcodiiga commented on GitHub (Apr 21, 2022):

Windows 10 (10.0.19044 Build 19044), wt 1.12.10982.0. It is affecting any path that I could try, not only root drives but also child dirs.

@marcodiiga commented on GitHub (Apr 21, 2022): Windows 10 (10.0.19044 Build 19044), wt 1.12.10982.0. It is affecting any path that I could try, not only root drives but also child dirs.
claunia commented 2026-01-31 05:38:48 +00:00
Author
Owner
Copy Link

@marcodiiga commented on GitHub (Apr 21, 2022):

I found a workaround to make this work: this opens up the shit+right-click context menu directory in Windows Terminal in the default profile (which I have set to Canonical's own profile).

image

@marcodiiga commented on GitHub (Apr 21, 2022): I found a workaround to make this work: this opens up the shit+right-click context menu directory in Windows Terminal in the default profile (which I have set to Canonical's own profile). ![image](https://user-images.githubusercontent.com/1969828/164497298-f015f110-68a3-4e39-8b49-d2b48406e0dd.png)
claunia commented 2026-01-31 05:38:48 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 21, 2022):

Oh heck that's probably it! I bet they've got the commandline of their profile set up so that it doesn't actually obey the startingDirectory!

@zadjii-msft commented on GitHub (Apr 21, 2022): Oh heck that's probably it! I bet they've got the `commandline` of their profile set up so that it doesn't actually obey the `startingDirectory`!
claunia commented 2026-01-31 05:38:48 +00:00
Author
Owner
Copy Link

@jacob-pro commented on GitHub (May 6, 2022):

Is your profile using wsl.exe -d Ubuntu or Ubuntu.exe?

The latter will not respect the starting directory, and always opens in $HOME

@jacob-pro commented on GitHub (May 6, 2022): Is your profile using `wsl.exe -d Ubuntu` or `Ubuntu.exe`? The latter will not respect the starting directory, and always opens in $HOME
claunia commented 2026-01-31 05:38:48 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 6, 2022):

The latter will not respect the starting directory, and always opens in $HOME

That's exactly it. There's definitely and issue with the Ubuntu profiles that Canonical is shipping. Sorry about that! I'm reaching out to them to see what we can do here.

@zadjii-msft commented on GitHub (May 6, 2022): > The latter will not respect the starting directory, and always opens in $HOME That's exactly it. There's definitely and issue with the Ubuntu profiles that Canonical is shipping. Sorry about that! I'm reaching out to them to see what we can do here.
claunia commented 2026-01-31 05:38:49 +00:00
Author
Owner
Copy Link

@trizotti commented on GitHub (Jun 27, 2022):

Same problem here after removing one of the distros I had installed; Windows Terminal settings also still recognizing two distros at the selection for the default one.

@trizotti commented on GitHub (Jun 27, 2022): Same problem here after removing one of the distros I had installed; Windows Terminal settings also still recognizing two distros at the selection for the default one.
claunia commented 2026-01-31 05:38:49 +00:00
Author
Owner
Copy Link

@elliason commented on GitHub (Aug 6, 2022):

I had the same problem with Ubuntu-22.04 installed via Microsoft Store. The terminal always started in /home/, no matter the current directory where context menu was invoked (on right click).
Adding "commandline": "wsl.exe -d Ubuntu-22.04 /bin/bash" to terminal profile fixed the issue.
image

@elliason commented on GitHub (Aug 6, 2022): I had the same problem with Ubuntu-22.04 installed via Microsoft Store. The terminal always started in /home/<wsl-user>, no matter the current directory where context menu was invoked (on right click). Adding `"commandline": "wsl.exe -d Ubuntu-22.04 /bin/bash"` to terminal profile fixed the issue. ![image](https://user-images.githubusercontent.com/6887123/183238742-d42642dc-645a-412b-87f8-cec23aa86378.png)
claunia commented 2026-01-31 05:38:49 +00:00
Author
Owner
Copy Link

@muhammedanaskhan commented on GitHub (Aug 6, 2022):

Is your profile using wsl.exe -d Ubuntu or Ubuntu.exe?

The latter will not respect the starting directory, and always opens in $HOME

WORKS!!!!!

@muhammedanaskhan commented on GitHub (Aug 6, 2022): > Is your profile using `wsl.exe -d Ubuntu` or `Ubuntu.exe`? > > The latter will not respect the starting directory, and always opens in $HOME WORKS!!!!!
claunia commented 2026-01-31 05:38:50 +00:00
Author
Owner
Copy Link

@nrobinson12 commented on GitHub (Oct 7, 2022):

Thanks for this! Managed to get it working by adding the commandLine to it. However, now when opening it normally, it will always open default to /mnt/c/WINDOWS/System32. Is there a way to keep opening in current directory context menu, while also having it open in the default /home directory when opening terminal on it's own?

@nrobinson12 commented on GitHub (Oct 7, 2022): Thanks for this! Managed to get it working by adding the `commandLine` to it. However, now when opening it normally, it will always open default to `/mnt/c/WINDOWS/System32`. Is there a way to keep opening in current directory context menu, while also having it open in the default `/home` directory when opening terminal on it's own?
claunia commented 2026-01-31 05:38:50 +00:00
Author
Owner
Copy Link

@iamLazyCode commented on GitHub (Jan 15, 2023):

Is your profile using wsl.exe -d Ubuntu or Ubuntu.exe?
The latter will not respect the starting directory, and always opens in $HOME

WORKS!!!!!

sir can you help me out , what i need to change here , please sir thankyou

"list":
[
{
"commandline": "%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe",
"guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
"hidden": false,
"name": "Windows PowerShell"
},
{
"commandline": "%SystemRoot%\System32\cmd.exe",
"guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
"hidden": false,
"name": "Command Prompt"
},
{
"guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}",
"hidden": false,
"name": "PowerShell",
"source": "Windows.Terminal.PowershellCore"
},
{
"guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
"hidden": false,
"name": "Azure Cloud Shell",
"source": "Windows.Terminal.Azure"
},
{
"commandline": "wsl.exe -d Ubuntu-22.04 /bin/bash",
"guid": "{51855cb2-8cce-5362-8f54-464b92b32386}",
"hidden": false,
"name": "Ubuntu",
"source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc"
},
{
"guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
"hidden": false,
"name": "Ubuntu",
"source": "Windows.Terminal.Wsl",
"startingDirectory": null
}
]

@iamLazyCode commented on GitHub (Jan 15, 2023): > > Is your profile using `wsl.exe -d Ubuntu` or `Ubuntu.exe`? > > The latter will not respect the starting directory, and always opens in $HOME > > WORKS!!!!! sir can you help me out , what i need to change here , please sir thankyou "list": [ { "commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe", "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "hidden": false, "name": "Windows PowerShell" }, { "commandline": "%SystemRoot%\\System32\\cmd.exe", "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}", "hidden": false, "name": "Command Prompt" }, { "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}", "hidden": false, "name": "PowerShell", "source": "Windows.Terminal.PowershellCore" }, { "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}", "hidden": false, "name": "Azure Cloud Shell", "source": "Windows.Terminal.Azure" }, { "commandline": "wsl.exe -d Ubuntu-22.04 /bin/bash", "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}", "hidden": false, "name": "Ubuntu", "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc" }, { "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}", "hidden": false, "name": "Ubuntu", "source": "Windows.Terminal.Wsl", "startingDirectory": null } ]
claunia commented 2026-01-31 05:38:50 +00:00
Author
Owner
Copy Link

@sergey-gr commented on GitHub (Feb 1, 2023):

Is your profile using wsl.exe -d Ubuntu or Ubuntu.exe?
The latter will not respect the starting directory, and always opens in $HOME

WORKS!!!!!

sir can you help me out , what i need to change here , please sir thankyou

"list": [ { "commandline": "%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe", "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "hidden": false, "name": "Windows PowerShell" }, { "commandline": "%SystemRoot%\System32\cmd.exe", "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}", "hidden": false, "name": "Command Prompt" }, { "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}", "hidden": false, "name": "PowerShell", "source": "Windows.Terminal.PowershellCore" }, { "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}", "hidden": false, "name": "Azure Cloud Shell", "source": "Windows.Terminal.Azure" }, { "commandline": "wsl.exe -d Ubuntu-22.04 /bin/bash", "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}", "hidden": false, "name": "Ubuntu", "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc" }, { "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}", "hidden": false, "name": "Ubuntu", "source": "Windows.Terminal.Wsl", "startingDirectory": null } ]

Check if you really have sat up right distro name:

Try to run from CMD or PS:

wsl -l -v

Then open terminal settings (json file).
Search for your profile and change "commandline" value to this:

"commandline": "C:\\windows\\System32\\wsl.exe -d Ubuntu-22.04",

or

"commandline": "wsl.exe -d Ubuntu-22.04",
@sergey-gr commented on GitHub (Feb 1, 2023): > > > Is your profile using `wsl.exe -d Ubuntu` or `Ubuntu.exe`? > > > The latter will not respect the starting directory, and always opens in $HOME > > > > > > WORKS!!!!! > > sir can you help me out , what i need to change here , please sir thankyou > > "list": [ { "commandline": "%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe", "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "hidden": false, "name": "Windows PowerShell" }, { "commandline": "%SystemRoot%\System32\cmd.exe", "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}", "hidden": false, "name": "Command Prompt" }, { "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}", "hidden": false, "name": "PowerShell", "source": "Windows.Terminal.PowershellCore" }, { "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}", "hidden": false, "name": "Azure Cloud Shell", "source": "Windows.Terminal.Azure" }, { "commandline": "wsl.exe -d Ubuntu-22.04 /bin/bash", "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}", "hidden": false, "name": "Ubuntu", "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc" }, { "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}", "hidden": false, "name": "Ubuntu", "source": "Windows.Terminal.Wsl", "startingDirectory": null } ] Check if you really have sat up right distro name: Try to run from CMD or PS: ```shell wsl -l -v ``` Then open terminal settings (json file). Search for your profile and change "commandline" value to this: ``` "commandline": "C:\\windows\\System32\\wsl.exe -d Ubuntu-22.04", ``` or ``` "commandline": "wsl.exe -d Ubuntu-22.04", ```
claunia commented 2026-01-31 05:38:51 +00:00
Author
Owner
Copy Link

@iamLazyCode commented on GitHub (Feb 1, 2023):

Is your profile using wsl.exe -d Ubuntu or Ubuntu.exe?
The latter will not respect the starting directory, and always opens in $HOME

WORKS!!!!!

sir can you help me out , what i need to change here , please sir thankyou
"list": [ { "commandline": "%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe", "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "hidden": false, "name": "Windows PowerShell" }, { "commandline": "%SystemRoot%\System32\cmd.exe", "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}", "hidden": false, "name": "Command Prompt" }, { "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}", "hidden": false, "name": "PowerShell", "source": "Windows.Terminal.PowershellCore" }, { "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}", "hidden": false, "name": "Azure Cloud Shell", "source": "Windows.Terminal.Azure" }, { "commandline": "wsl.exe -d Ubuntu-22.04 /bin/bash", "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}", "hidden": false, "name": "Ubuntu", "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc" }, { "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}", "hidden": false, "name": "Ubuntu", "source": "Windows.Terminal.Wsl", "startingDirectory": null } ]

Check if you really have sat up right distro name:

Try to run from CMD or PS:

wsl -l -v

Then open terminal settings (json file). Search for your profile and change "commandline" value to this:

"commandline": "C:\\windows\\System32\\wsl.exe -d Ubuntu-22.04",

or

"commandline": "wsl.exe -d Ubuntu-22.04",

i just cant thankyou enough this worked like a charm...thankyou once again just one more thing if u can help sir ...some icon error

image

@iamLazyCode commented on GitHub (Feb 1, 2023): > > > > Is your profile using `wsl.exe -d Ubuntu` or `Ubuntu.exe`? > > > > The latter will not respect the starting directory, and always opens in $HOME > > > > > > > > > WORKS!!!!! > > > > > > sir can you help me out , what i need to change here , please sir thankyou > > "list": [ { "commandline": "%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe", "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "hidden": false, "name": "Windows PowerShell" }, { "commandline": "%SystemRoot%\System32\cmd.exe", "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}", "hidden": false, "name": "Command Prompt" }, { "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}", "hidden": false, "name": "PowerShell", "source": "Windows.Terminal.PowershellCore" }, { "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}", "hidden": false, "name": "Azure Cloud Shell", "source": "Windows.Terminal.Azure" }, { "commandline": "wsl.exe -d Ubuntu-22.04 /bin/bash", "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}", "hidden": false, "name": "Ubuntu", "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc" }, { "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}", "hidden": false, "name": "Ubuntu", "source": "Windows.Terminal.Wsl", "startingDirectory": null } ] > > Check if you really have sat up right distro name: > > Try to run from CMD or PS: > > ```shell > wsl -l -v > ``` > > Then open terminal settings (json file). Search for your profile and change "commandline" value to this: > > ``` > "commandline": "C:\\windows\\System32\\wsl.exe -d Ubuntu-22.04", > ``` > > or > > ``` > "commandline": "wsl.exe -d Ubuntu-22.04", > ``` i just cant thankyou enough this worked like a charm...thankyou once again just one more thing if u can help sir ...some icon error ![image](https://user-images.githubusercontent.com/13099434/216150914-701ed7fa-d085-4cde-b525-ce350da263a3.png)
claunia commented 2026-01-31 05:38:51 +00:00
Author
Owner
Copy Link

@sergey-gr commented on GitHub (Feb 2, 2023):

Is your profile using wsl.exe -d Ubuntu or Ubuntu.exe?
The latter will not respect the starting directory, and always opens in $HOME

WORKS!!!!!

sir can you help me out , what i need to change here , please sir thankyou
"list": [ { "commandline": "%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe", "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "hidden": false, "name": "Windows PowerShell" }, { "commandline": "%SystemRoot%\System32\cmd.exe", "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}", "hidden": false, "name": "Command Prompt" }, { "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}", "hidden": false, "name": "PowerShell", "source": "Windows.Terminal.PowershellCore" }, { "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}", "hidden": false, "name": "Azure Cloud Shell", "source": "Windows.Terminal.Azure" }, { "commandline": "wsl.exe -d Ubuntu-22.04 /bin/bash", "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}", "hidden": false, "name": "Ubuntu", "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc" }, { "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}", "hidden": false, "name": "Ubuntu", "source": "Windows.Terminal.Wsl", "startingDirectory": null } ]

Check if you really have sat up right distro name:
Try to run from CMD or PS:

wsl -l -v

Then open terminal settings (json file). Search for your profile and change "commandline" value to this:

"commandline": "C:\\windows\\System32\\wsl.exe -d Ubuntu-22.04",

or

"commandline": "wsl.exe -d Ubuntu-22.04",

i just cant thankyou enough this worked like a charm...thankyou once again just one more thing if u can help sir ...some icon error

image

You can pick icon from the internet, by setting Icon value to:

https://assets.ubuntu.com/v1/49a1a858-favicon-32x32.png

Or download and save it on your computer, then just set correct path to the icon.

For example I use one of local app icons (Linux icon):

ms-appx:///ProfileIcons/{9acb9455-ca41-5af7-950f-6bca1bc9722f}.png
@sergey-gr commented on GitHub (Feb 2, 2023): > > > > > Is your profile using `wsl.exe -d Ubuntu` or `Ubuntu.exe`? > > > > > The latter will not respect the starting directory, and always opens in $HOME > > > > > > > > > > > > WORKS!!!!! > > > > > > > > > sir can you help me out , what i need to change here , please sir thankyou > > > "list": [ { "commandline": "%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe", "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "hidden": false, "name": "Windows PowerShell" }, { "commandline": "%SystemRoot%\System32\cmd.exe", "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}", "hidden": false, "name": "Command Prompt" }, { "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}", "hidden": false, "name": "PowerShell", "source": "Windows.Terminal.PowershellCore" }, { "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}", "hidden": false, "name": "Azure Cloud Shell", "source": "Windows.Terminal.Azure" }, { "commandline": "wsl.exe -d Ubuntu-22.04 /bin/bash", "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}", "hidden": false, "name": "Ubuntu", "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc" }, { "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}", "hidden": false, "name": "Ubuntu", "source": "Windows.Terminal.Wsl", "startingDirectory": null } ] > > > > > > Check if you really have sat up right distro name: > > Try to run from CMD or PS: > > ```shell > > wsl -l -v > > ``` > > > > > > > > > > > > > > > > > > > > > > > > Then open terminal settings (json file). Search for your profile and change "commandline" value to this: > > ``` > > "commandline": "C:\\windows\\System32\\wsl.exe -d Ubuntu-22.04", > > ``` > > > > > > > > > > > > > > > > > > > > > > > > or > > ``` > > "commandline": "wsl.exe -d Ubuntu-22.04", > > ``` > > i just cant thankyou enough this worked like a charm...thankyou once again just one more thing if u can help sir ...some icon error > > ![image](https://user-images.githubusercontent.com/13099434/216150914-701ed7fa-d085-4cde-b525-ce350da263a3.png) > You can pick icon from the internet, by setting Icon value to: ``` https://assets.ubuntu.com/v1/49a1a858-favicon-32x32.png ``` Or download and save it on your computer, then just set correct path to the icon. For example I use one of local app icons (Linux icon): ``` ms-appx:///ProfileIcons/{9acb9455-ca41-5af7-950f-6bca1bc9722f}.png ```
claunia commented 2026-01-31 05:38:51 +00:00
Author
Owner
Copy Link

@iamLazyCode commented on GitHub (Feb 2, 2023):

Is your profile using wsl.exe -d Ubuntu or Ubuntu.exe?
The latter will not respect the starting directory, and always opens in $HOME

WORKS!!!!!

sir can you help me out , what i need to change here , please sir thankyou
"list": [ { "commandline": "%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe", "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "hidden": false, "name": "Windows PowerShell" }, { "commandline": "%SystemRoot%\System32\cmd.exe", "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}", "hidden": false, "name": "Command Prompt" }, { "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}", "hidden": false, "name": "PowerShell", "source": "Windows.Terminal.PowershellCore" }, { "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}", "hidden": false, "name": "Azure Cloud Shell", "source": "Windows.Terminal.Azure" }, { "commandline": "wsl.exe -d Ubuntu-22.04 /bin/bash", "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}", "hidden": false, "name": "Ubuntu", "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc" }, { "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}", "hidden": false, "name": "Ubuntu", "source": "Windows.Terminal.Wsl", "startingDirectory": null } ]

Check if you really have sat up right distro name:
Try to run from CMD or PS:

wsl -l -v

Then open terminal settings (json file). Search for your profile and change "commandline" value to this:

"commandline": "C:\\windows\\System32\\wsl.exe -d Ubuntu-22.04",

or

"commandline": "wsl.exe -d Ubuntu-22.04",

i just cant thankyou enough this worked like a charm...thankyou once again just one more thing if u can help sir ...some icon error
image

You can pick icon from the internet, by setting Icon value to:

https://assets.ubuntu.com/v1/49a1a858-favicon-32x32.png

Or download and save it on your computer, then just set correct path to the icon.

For example I use one of local app icons (Linux icon):

ms-appx:///ProfileIcons/{9acb9455-ca41-5af7-950f-6bca1bc9722f}.png

thankyou so much will try later in evening , thankyou again sir

@iamLazyCode commented on GitHub (Feb 2, 2023): > > > > > > Is your profile using `wsl.exe -d Ubuntu` or `Ubuntu.exe`? > > > > > > The latter will not respect the starting directory, and always opens in $HOME > > > > > > > > > > > > > > > WORKS!!!!! > > > > > > > > > > > > sir can you help me out , what i need to change here , please sir thankyou > > > > "list": [ { "commandline": "%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe", "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "hidden": false, "name": "Windows PowerShell" }, { "commandline": "%SystemRoot%\System32\cmd.exe", "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}", "hidden": false, "name": "Command Prompt" }, { "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}", "hidden": false, "name": "PowerShell", "source": "Windows.Terminal.PowershellCore" }, { "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}", "hidden": false, "name": "Azure Cloud Shell", "source": "Windows.Terminal.Azure" }, { "commandline": "wsl.exe -d Ubuntu-22.04 /bin/bash", "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}", "hidden": false, "name": "Ubuntu", "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc" }, { "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}", "hidden": false, "name": "Ubuntu", "source": "Windows.Terminal.Wsl", "startingDirectory": null } ] > > > > > > > > > Check if you really have sat up right distro name: > > > Try to run from CMD or PS: > > > ```shell > > > wsl -l -v > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Then open terminal settings (json file). Search for your profile and change "commandline" value to this: > > > ``` > > > "commandline": "C:\\windows\\System32\\wsl.exe -d Ubuntu-22.04", > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > or > > > ``` > > > "commandline": "wsl.exe -d Ubuntu-22.04", > > > ``` > > > > > > i just cant thankyou enough this worked like a charm...thankyou once again just one more thing if u can help sir ...some icon error > > ![image](https://user-images.githubusercontent.com/13099434/216150914-701ed7fa-d085-4cde-b525-ce350da263a3.png) > > > > > You can pick icon from the internet, by setting Icon value to: > > ``` > https://assets.ubuntu.com/v1/49a1a858-favicon-32x32.png > ``` > > Or download and save it on your computer, then just set correct path to the icon. > > For example I use one of local app icons (Linux icon): > > ``` > ms-appx:///ProfileIcons/{9acb9455-ca41-5af7-950f-6bca1bc9722f}.png > ``` thankyou so much will try later in evening , thankyou again sir
claunia commented 2026-01-31 05:38:51 +00:00
Author
Owner
Copy Link

@mrtumnus commented on GitHub (May 31, 2023):

Came here to report that using ubuntu.exe DOES work with the run command proceeding, which starts the default shell in the current directory (where invoked). So, for my Windows Terminal profile, I have the following in the Command Line setting:

ubuntu.exe run

I would like to see the default change to use this setting value.

Source

@mrtumnus commented on GitHub (May 31, 2023): Came here to report that using `ubuntu.exe` DOES work with the `run` command proceeding, which starts the default shell in the current directory (where invoked). So, for my Windows Terminal profile, I have the following in the Command Line setting: ubuntu.exe run I would like to see the default change to use this setting value. [Source](https://stackoverflow.com/a/61073056/973624)
claunia commented 2026-01-31 05:38:52 +00:00
Author
Owner
Copy Link

@mrtumnus commented on GitHub (Jun 9, 2023):

Thanks for this! Managed to get it working by adding the commandLine to it. However, now when opening it normally, it will always open default to /mnt/c/WINDOWS/System32. Is there a way to keep opening in current directory context menu, while also having it open in the default /home directory when opening terminal on it's own?

The ubuntu.exe run method also has this problem. Anyone have ideas? I assume this is because the starting directory for wt.exe by default is the system directory (C:\WINDOWS\system32).

EDIT: I can create a shortcut to the wt.exe executable and set the starting location to my WSL $HOME (\wsl.localhost\Ubuntu\home<user>), but I can't pin the shortcut to the taskbar and have it merge with any open Terminal windows.

@mrtumnus commented on GitHub (Jun 9, 2023): > Thanks for this! Managed to get it working by adding the `commandLine` to it. However, now when opening it normally, it will always open default to `/mnt/c/WINDOWS/System32`. Is there a way to keep opening in current directory context menu, while also having it open in the default `/home` directory when opening terminal on it's own? The `ubuntu.exe run` method also has this problem. Anyone have ideas? I assume this is because the starting directory for wt.exe by default is the system directory (C:\WINDOWS\system32). EDIT: I can create a shortcut to the wt.exe executable and set the starting location to my WSL $HOME (\\wsl.localhost\Ubuntu\home\<user>), but I can't pin the shortcut to the taskbar and have it merge with any open Terminal windows.
claunia commented 2026-01-31 05:38:52 +00:00
Author
Owner
Copy Link

@mrtumnus commented on GitHub (Jun 9, 2023):

Workaround - add the following in .bashrc inside WSL:

# Change starting directory for the default system directory
if [ "$PWD" = "/mnt/c/WINDOWS/system32" ]; then
  cd ~
fi
@mrtumnus commented on GitHub (Jun 9, 2023): Workaround - add the following in `.bashrc` inside WSL: ``` # Change starting directory for the default system directory if [ "$PWD" = "/mnt/c/WINDOWS/system32" ]; then cd ~ fi ```
claunia commented 2026-01-31 05:38:52 +00:00
Author
Owner
Copy Link

@mrtumnus commented on GitHub (Jun 9, 2023):

Interesting - canonical is shipping their own profile, but not one layered with the existing profile. Curious....

Did you ever figure out why we have two? Which one should we use?

@mrtumnus commented on GitHub (Jun 9, 2023): > Interesting - canonical is shipping their own profile, but not one layered with the existing profile. Curious.... Did you ever figure out why we have two? Which one should we use?
claunia commented 2026-01-31 05:38:53 +00:00
Author
Owner
Copy Link

@nrobinson12 commented on GitHub (Jun 10, 2023):

Workaround - add the following in .bashrc inside WSL:

# Change starting directory for the default system directory
if [ "$PWD" = "/mnt/c/WINDOWS/system32" ]; then
  cd ~
fi

Thank you! Why didn't I think of this?

@nrobinson12 commented on GitHub (Jun 10, 2023): > Workaround - add the following in `.bashrc` inside WSL: > > ``` > # Change starting directory for the default system directory > if [ "$PWD" = "/mnt/c/WINDOWS/system32" ]; then > cd ~ > fi > ``` Thank you! Why didn't I think of this?
claunia commented 2026-01-31 05:38:53 +00:00
Author
Owner
Copy Link

@mrtumnus commented on GitHub (Jun 10, 2023):

Thank you! Why didn't I think of this?

Can't really think of a downside, unless you explicitly want to open terminal in the system directory.

The only thing that still doesn't work with this setup is opening terminal within a network share. It ends up landing in $HOME in this case. Still have to look around issues here to see if it's reported already.

@mrtumnus commented on GitHub (Jun 10, 2023): > Thank you! Why didn't I think of this? Can't really think of a downside, unless you explicitly want to open terminal in the system directory. The only thing that still doesn't work with this setup is opening terminal within a network share. It ends up landing in `$HOME` in this case. Still have to look around issues here to see if it's reported already.
claunia commented 2026-01-31 05:38:54 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 12, 2023):

The only thing that still doesn't work with this setup is opening terminal within a network share. It ends up landing in $HOME in this case. Still have to look around issues here to see if it's reported already.

WSL does not automatically map network shares. It cannot be launched in any directory that is not represented or representable in the Linux filesystem. You would need to mount them explicitly in /etc/fstab, and even then it may not be able to figure it out.

This would make an excellent feature request for the WSL repo 😄

@DHowett commented on GitHub (Jun 12, 2023): > The only thing that still doesn't work with this setup is opening terminal within a network share. It ends up landing in `$HOME` in this case. Still have to look around issues here to see if it's reported already. WSL does not automatically map network shares. It cannot be launched in any directory that is not represented or representable in the Linux filesystem. You would need to mount them explicitly in `/etc/fstab`, and even then it may not be able to figure it out. This would make an excellent feature request for [the WSL repo](https://github.com/microsoft/wsl) :smile:
claunia commented 2026-01-31 05:38:54 +00:00
Author
Owner
Copy Link

@mrtumnus commented on GitHub (Jun 12, 2023):

WSL does not automatically map network shares.

I could have sworn I had this working in WSL2. But I could be getting confused with my previous cygwin setup.

@mrtumnus commented on GitHub (Jun 12, 2023): > WSL does not automatically map network shares. I could have sworn I had this working in WSL2. But I could be getting confused with my previous cygwin setup.
claunia commented 2026-01-31 05:38:54 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 12, 2023):

Ah, even WSL 1 doesn't automatically map network shares.

@DHowett commented on GitHub (Jun 12, 2023): Ah, even WSL 1 doesn't automatically map network shares.
claunia commented 2026-01-31 05:38:55 +00:00
Author
Owner
Copy Link

@pbodnar commented on GitHub (Jul 23, 2023):

Interesting - canonical is shipping their own profile, but not one layered with the existing profile. Curious....

Did you ever figure out why we have two? Which one should we use?

Exactly my question. Why are 2 profiles generated and the bad one is enabled and not vice versa?

From all the related bugs, the profile generated by ? (with the Tux icon) is the correct one and the one generated by Canonical (with the Ubuntu icon, ubuntu.exe) is wrong. So why is it so that both profiles are generated and moreover that the correct one is disabled by default? Basically, it comes to the question, why the WSL / Terminal team cannot do anything about this (yet)?

IMO, from user's perspective, this seems absurd, so it would deserve at least a short explanation. And also a dedicated issue like #15560 - @zadjii-msft, are you really sure you want to continue the discussion here, where logically stuff quite unrelated to this profiles bug (like "mapping network shares" just above) were and will be discussed?

Anyway, thank you guys for pushing this further, I believe this confuses tons of people and is a huge waste of time in the sum.

@pbodnar commented on GitHub (Jul 23, 2023): > > Interesting - canonical is shipping their own profile, but not one layered with the existing profile. Curious.... > > Did you ever figure out why we have two? Which one should we use? Exactly my question. Why are 2 profiles generated and the bad one is enabled and not vice versa? From all the related bugs, the profile **generated by ?** (with the Tux icon) is the correct one and the one **generated by Canonical** (with the Ubuntu icon, `ubuntu.exe`) is wrong. So why is it so that both profiles are generated and _moreover_ that the correct one is disabled by default? Basically, it comes to the question, **why** the WSL / Terminal team cannot do anything about this (yet)? IMO, from user's perspective, this seems absurd, so it would deserve at least a short explanation. And also a dedicated issue like #15560 - @zadjii-msft, are you really sure you want to continue the discussion _here_, where logically stuff quite unrelated to this profiles bug (like "mapping network shares" just above) were and will be discussed? Anyway, thank you guys for pushing this further, I believe this confuses tons of people and is a huge waste of time in the sum.
claunia commented 2026-01-31 05:38:55 +00:00
Author
Owner
Copy Link

@TBBle commented on GitHub (Aug 20, 2024):

From all the related bugs, the profile generated by ? (with the Tux icon) is the correct one and the one generated by Canonical (with the Ubuntu icon, ubuntu.exe) is wrong. So why is it so that both profiles are generated and moreover that the correct one is disabled by default? Basically, it comes to the question, why the WSL / Terminal team cannot do anything about this (yet)?

This is a choice in the Canonical code snippet, it creates a new profile and (attempts to) disable the built-in generator's profile. Nothing we can do about it in the WT code except break that feature, which seems unlikely to be an acceptable choice.

Having just help a user hitting this issue starting from https://github.com/microsoft/terminal/issues/3158#issuecomment-2295720051, here's what appears to be the current state of making the Ubuntu-provided profile (or any other WSL distribution's custom profile) work, thanks to comments earlier in this ticket, and some testing by the user having the issue.

If you want to use the Ubuntu generated profile, you need to do one of two things:

  1. Add a snippet like this to the generated profile, mirroring the built-in settings from the WSL-provided profile and hence activating a wsl.exe-specific codepath.
    "commandline": "wsl.exe -d Ubuntu-22.04",
    "startingDirectory": "~",

Note that this approach loses anything the Ubuntu launcher does before it chains out into wsl.exe. I think that is only first-run stuff, but I expect it does make this approach a non-starter for the Ubuntu-provided snippet.

  1. Add a snippet like this to the generated profile, getting the desired "don't override CWD" behaviour from the Ubuntu-provided launcher with the run argument plus an explicit default startingDirectory to not start in C:\Windows\System32:
    "commandline": "ubuntu2204.exe run",
    "startingDirectory": "\\\\wsl$\\Ubuntu-2404\\home\\<yourWSLAccountName>",

You can get the startingDirectory value for option 2 from inside Ubuntu by going to the desired directory and running wslpath -w "$PWD", or browsing from \\wsl$ or \\wsl.localhost in Windows Explorer.

In both cases the commandline value will depend on the existing command-line: If you do it in the GUI editor, you should see the existing command line.

Both approaches should make both "open-in-current-directory folder context menu" and "OSC9;9 duplicate current session" work, as AFAIK they rely on being able to override the profile's defined startingDirectory, as does wt newtab -d. However, neither approach will make drag-and-drop path mangling work.

Note that if you're adding cd calls to your bash startup scripts, they should not be necessary with the above two approaches. You can still use https://github.com/microsoft/terminal/issues/12961#issuecomment-1584764956 to avoid setting the startingDirectory with only the minor cost of not being able to start in C:\Windows\System32... And it not working if you aren't actually running bash. So I personally disprefer this approach.

There's two current code-paths in WT that are issues for this ticket AFAIK:

So there's probably some low-hanging fruit for someone to unify those two hacks to both work the same way. (Of the two hacks, I think matching wsl.exe is better than checking the profileSource, since approach 1 above has fewer side-effects that changing the profileSource value would have)

And some higher-branch fruit to then expose them as not-hacks by perhaps either detecting WSL or exposing an isWSL flag in the profile that activates both hacks and probably also provides a default "startingDirectory": "~" value.

Other solutions are possible, of course, and I make no suggestion on the acceptability of my suggestions to the WT maintainers.

@TBBle commented on GitHub (Aug 20, 2024): > From all the related bugs, the profile **generated by ?** (with the Tux icon) is the correct one and the one **generated by Canonical** (with the Ubuntu icon, `ubuntu.exe`) is wrong. So why is it so that both profiles are generated and _moreover_ that the correct one is disabled by default? Basically, it comes to the question, **why** the WSL / Terminal team cannot do anything about this (yet)? This is a choice in the Canonical code snippet, it creates a new profile and (attempts to) disable the built-in generator's profile. Nothing we can do about it in the WT code except break that feature, which seems unlikely to be an acceptable choice. ---- Having just help a user hitting this issue starting from https://github.com/microsoft/terminal/issues/3158#issuecomment-2295720051, here's what appears to be the current state of making the Ubuntu-provided profile (or any other WSL distribution's custom profile) work, thanks to comments earlier in this ticket, and some testing by the user having the issue. If you want to use the Ubuntu generated profile, you need to do one of two things: 1. Add a snippet like this to the generated profile, mirroring the built-in settings from the WSL-provided profile and hence activating a wsl.exe-specific codepath. ```json "commandline": "wsl.exe -d Ubuntu-22.04", "startingDirectory": "~", ``` Note that this approach loses anything the Ubuntu launcher does before it chains out into wsl.exe. I _think_ that is only first-run stuff, but I expect it does make this approach a non-starter for the Ubuntu-provided snippet. 2. Add a snippet like this to the generated profile, getting the desired "don't override CWD" behaviour from the Ubuntu-provided launcher [with the `run` argument](https://github.com/microsoft/terminal/issues/12961#issuecomment-1570584225) plus an explicit default `startingDirectory` to not start in `C:\Windows\System32`: ```json "commandline": "ubuntu2204.exe run", "startingDirectory": "\\\\wsl$\\Ubuntu-2404\\home\\<yourWSLAccountName>", ``` You can get the `startingDirectory` value for option 2 from inside Ubuntu by going to the desired directory and running `wslpath -w "$PWD"`, or browsing from `\\wsl$` or `\\wsl.localhost` in Windows Explorer. In both cases the `commandline` value will depend on the existing command-line: If you do it in the GUI editor, you should see the existing command line. Both approaches should make both "open-in-current-directory folder context menu" and "OSC9;9 duplicate current session" work, as AFAIK they rely on being able to override the profile's defined `startingDirectory`, as does `wt newtab -d`. However, neither approach will make drag-and-drop path mangling work. Note that if you're adding `cd` calls to your bash startup scripts, they should not be necessary with the above two approaches. You can still use https://github.com/microsoft/terminal/issues/12961#issuecomment-1584764956 to avoid setting the `startingDirectory` with only the minor cost of not being able to start in `C:\Windows\System32`... And it not working if you aren't actually running bash. So I personally disprefer this approach. ---- There's two current code-paths in WT that are issues for this ticket AFAIK: * Code that handles ` "startingDirectory": "~",` [depends on the commandline starting with `wsl.exe` or `C:\Windows\System32\wsl.exe`.](https://github.com/microsoft/terminal/blob/735ef2823ed72d80ce91df0176646979e4568831/src/types/utils.cpp#L1017-L1021). Without it, you have to provide the full path to your WSL user's home directory. (~~This code could be improved to only pass `--cd` on the command-line when the `startingDirectory` is `~` or starts with `~`, as those are the only times it actually matters.~~ Edit: See following comment for correction) * Code that handles drag-and-drop path mangling [depends on the `profileSource` being literally `Windows.Terminal.Wsl`.](https://github.com/microsoft/terminal/blob/735ef2823ed72d80ce91df0176646979e4568831/src/cascadia/TerminalControl/ControlInteractivity.cpp#L728-L739) So there's probably some low-hanging fruit for someone to unify those two hacks to both work the same way. (Of the two hacks, I think matching wsl.exe is better than checking the `profileSource`, since approach 1 above has fewer side-effects that changing the `profileSource` value would have) And some higher-branch fruit to then expose them as not-hacks by perhaps either detecting WSL or exposing an `isWSL` flag in the profile that activates both hacks and probably also provides a default `"startingDirectory": "~"` value. Other solutions are possible, of course, and I make no suggestion on the _acceptability_ of my suggestions to the WT maintainers.
claunia commented 2026-01-31 05:38:56 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 20, 2024):

This code could be improved to only pass --cd on the command-line when the startingDirectory is ~ or starts with ~, as those are the only times it actually matters.

Thanks for the investigation! One note about this: we use --cd to support startingDirectory set to things like /root or perhaps more saliently /tank/projects/foo. It does not only apply to homedir based paths.

@DHowett commented on GitHub (Aug 20, 2024): > This code could be improved to only pass --cd on the command-line when the startingDirectory is ~ or starts with ~, as those are the only times it actually matters. Thanks for the investigation! One note about this: we use `--cd` to support `startingDirectory` set to things like `/root` or perhaps more saliently `/tank/projects/foo`. It does not only apply to homedir based paths.
claunia commented 2026-01-31 05:38:56 +00:00
Author
Owner
Copy Link

@TBBle commented on GitHub (Aug 20, 2024):

Ah, yes. I misparsed the code: the ~ check I skimmed over is an exclusion check for the provided command-line.

So it does make sense to use --cd in the case where we know it exists (I'm not sure if the template WSL Distribution Launcher handles it, on consideration, as I don't know if that's handled by wsl.exe directly, or by the underlying API shared by the template WSL Distribution Launcher), even though it's not needed for Windows-filesystem paths, rather than trying to distinguish them here.

@TBBle commented on GitHub (Aug 20, 2024): Ah, yes. I misparsed the code: the `~` check I skimmed over is an exclusion check for the provided command-line. So it does make sense to use `--cd` in the case where we know it exists (I'm not sure if the template WSL Distribution Launcher handles it, on consideration, as I don't know if that's handled by wsl.exe directly, or by the underlying API shared by the template WSL Distribution Launcher), even though it's not needed for Windows-filesystem paths, rather than trying to distinguish them here.
claunia commented 2026-01-31 05:38:57 +00:00
Author
Owner
Copy Link

@reardonia commented on GitHub (Sep 28, 2024):

Is there any way to extract the value set via OSC9;9 and use within "commandline" ? How do we generalize the dup functionality to work for ssh sessions (and other arbitrary commands)? It seems like it can only be used for WSL/cmd/PS sessions.

something like :
{ "commandline": "ssh.exe -t myname@myserver \" cd %PWD% ; bash --login \" ", }

@reardonia commented on GitHub (Sep 28, 2024): Is there any way to extract the value set via OSC9;9 and use within "commandline" ? How do we generalize the dup functionality to work for ssh sessions (and other arbitrary commands)? It seems like it can only be used for WSL/cmd/PS sessions. something like : ` { "commandline": "ssh.exe -t myname@myserver \" cd %PWD% ; bash --login \" ", } `
claunia commented 2026-01-31 05:38:57 +00:00
Author
Owner
Copy Link

@TBBle commented on GitHub (Sep 28, 2024):

I think that this is the wrong ticket for this question...?

But no, I don't think that data is currently exposed in env-vars or otherwise, it's only used to set the starting directory for the new process as far as I can see. (But I only quickly checked the code for launching processes on GitHub, so it's possible it's exposed somehow elsewhere and I overlooked it.)

That should already work for arbitrary commands, as long as they also output OSC9;9 escapes to set the value, e.g., vim.exe could be used with the current system with a vim plugin that outputs OSC9;9 when you change CWD inside vim use :cd or autochdir by hooking the DirChanged autocmd. It's only specific things like ssh or plink where the process's starting directory is not where we actually need this information.

So you would need to open a feature request ticket if you want that available.

Note that OSC9;9 paths are Windows paths, so unless you're SSHing to a Windows server, it won't be the right value for you anyway. For that, you'll need OSC7 support, and we don't have that in Windows Terminal yet, it's being "tracked" in #3158.

But maybe the resolution to the long standing "OSC7 semantics are challenging and ill-defined" issue for us could be as simple as "Capture OSC7, and expose it as an env-var in duplicate tabs so people can use a commandline like ssh.exe -t myname@myserver \"cd %WT_OSC7_PATH% ; exec ${SHELL}\" or wsl.exe -d Ubuntu-22.04 --cd %WT_OSC7_PATH% on their own recognisance", and not try and actually implement any specific behaviour for OSC7, since OSC9;9 fills its use-case in all situations that WT should care about: setting the starting directory for the new process.

Okay maybe it is relevant to this ticket; if WT_OSC7_PATH defaulted to startingDirectory when that is a POSIX-style path, then this pattern might let us remove one of the WSL-specific hacks (at the cost of putting it explicitly in the WSL profile commandline), or at least simplify it to implicitly adding literal --cd %WT_OSC7_PATH% before env-var handling.

But I still think the general idea of "Capture OSC7 and expose it as an env-var for commandlines/processes to use as they see fit" might be worth a feature request. (That would also let us close #3158 as "We're not using OSC7 for automatic CWD setting, we only support OSC9;9 for that"...)

@TBBle commented on GitHub (Sep 28, 2024): I think that this is the wrong ticket for this question...? But no, I don't think that data is currently exposed in env-vars or otherwise, it's only used to set the starting directory for the new process as far as I can see. (But I only quickly checked [the code for launching processes](https://github.com/microsoft/terminal/blob/v1.22.2702.0/src/cascadia/TerminalConnection/ConptyConnection.cpp#L59-L100) on GitHub, so it's possible it's exposed somehow elsewhere and I overlooked it.) That _should_ already work for arbitrary commands, as long as they also output OSC9;9 escapes to _set_ the value, e.g., `vim.exe` could be used with the current system with a vim plugin that outputs OSC9;9 when you change CWD inside vim use `:cd` or `autochdir` by hooking [the `DirChanged` autocmd](https://vimhelp.org/autocmd.txt.html#DirChanged). It's only specific things like ssh or plink where the process's starting directory is not where we actually need this information. So you would need to open a feature request ticket if you want that available. Note that OSC9;9 paths are _Windows_ paths, so unless you're SSHing to a Windows server, it won't be the right value for you anyway. For that, you'll need OSC7 support, and we don't have that in Windows Terminal yet, it's being "tracked" in #3158. But maybe the resolution to the _long standing_ "OSC7 semantics are [challenging](https://github.com/microsoft/terminal/issues/8214) and [ill-defined](https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/20)" issue for us could be as simple as "Capture OSC7, and expose it as an env-var in duplicate tabs so people can use a commandline like `ssh.exe -t myname@myserver \"cd %WT_OSC7_PATH% ; exec ${SHELL}\"` or `wsl.exe -d Ubuntu-22.04 --cd %WT_OSC7_PATH%` on their own recognisance", and not try and actually implement any specific behaviour for OSC7, since OSC9;9 fills its use-case in all situations that WT _should_ care about: setting the starting directory for the new process. Okay maybe it is relevant to this ticket; if `WT_OSC7_PATH` defaulted to `startingDirectory` when that is a POSIX-style path, then this pattern might let us remove one of the WSL-specific hacks (at the cost of putting it explicitly in the WSL profile commandline), or at least simplify it to implicitly adding literal `--cd %WT_OSC7_PATH%` before env-var handling. But I still think the general idea of "Capture OSC7 and expose it as an env-var for commandlines/processes to use as they see fit" might be worth a feature request. (That would also let us close #3158 as "We're not using OSC7 for automatic CWD setting, we only support OSC9;9 for that"...)
claunia commented 2026-01-31 05:38:58 +00:00
Author
Owner
Copy Link

@reardonia commented on GitHub (Sep 28, 2024):

Note that OSC9;9 paths are Windows paths, so unless you're SSHing to a Windows server, it won't be the right value for you anyway. For that, you'll need OSC7 support, and we don't have that in Windows Terminal yet, it's being "tracked" in #3158.

Hmm, I don't think that's right? For instance, from a WSL session I can emit OSC9;9 with a linux path, using "\w" escape that bash understands with PS1 environment variable. I don't have to "window-ize" the path using wslpath. Focus-panes duplicate properly and inherent the PWD.

It's not at all clear in the code that OSC9;9 can only refer to a Windows path? (though I am new to this codebase, I just scanned quickly)

@reardonia commented on GitHub (Sep 28, 2024): > Note that OSC9;9 paths are _Windows_ paths, so unless you're SSHing to a Windows server, it won't be the right value for you anyway. For that, you'll need OSC7 support, and we don't have that in Windows Terminal yet, it's being "tracked" in #3158. > Hmm, I don't think that's right? For instance, from a WSL session I can emit OSC9;9 with a linux path, using "\w" escape that bash understands with PS1 environment variable. I don't have to "window-ize" the path using wslpath. Focus-panes duplicate properly and inherent the PWD. It's not at all clear in the code that OSC9;9 can only refer to a Windows path? (though I am new to this codebase, I just scanned quickly)
claunia commented 2026-01-31 05:38:58 +00:00
Author
Owner
Copy Link

@reardonia commented on GitHub (Sep 28, 2024):

But maybe the resolution to the long standing "OSC7 semantics are challenging and ill-defined" issue for us could be as simple as "Capture OSC7, and expose it as an env-var in duplicate tabs so people can use a commandline like ssh.exe -t myname@myserver \"cd %WT_OSC7_PATH% ; exec ${SHELL}\" or wsl.exe -d Ubuntu-22.04 --cd %WT_OSC7_PATH% on their own recognisance", and not try and actually implement any specific behaviour for OSC7, since OSC9;9 fills its use-case in all situations that WT should care about: setting the starting directory for the new process.

Okay maybe it is relevant to this ticket; if WT_OSC7_PATH defaulted to startingDirectory when that is a POSIX-style path, then this pattern might let us remove one of the WSL-specific hacks (at the cost of putting it explicitly in the WSL profile commandline), or at least simplify it to implicitly adding literal --cd %WT_OSC7_PATH% before env-var handling.

But I still think the general idea of "Capture OSC7 and expose it as an env-var for commandlines/processes to use as they see fit" might be worth a feature request. (That would also let us close #3158 as "We're not using OSC7 for automatic CWD setting, we only support OSC9;9 for that"...)

I'd happy with either OSC7 or OSC9;9 turning into an env var, and dropping WSL-specific hack. I don't totally follow the argument for why OSC9;9 was introduced vs reusing OSC7 but I'll leave that to others who've thought about it longer/harder.

EDIT: I just found MangleStartingDirectoryForWSL() ... YUCK!

@reardonia commented on GitHub (Sep 28, 2024): > But maybe the resolution to the _long standing_ "OSC7 semantics are [challenging](https://github.com/microsoft/terminal/issues/8214) and [ill-defined](https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/20)" issue for us could be as simple as "Capture OSC7, and expose it as an env-var in duplicate tabs so people can use a commandline like `ssh.exe -t myname@myserver \"cd %WT_OSC7_PATH% ; exec ${SHELL}\"` or `wsl.exe -d Ubuntu-22.04 --cd %WT_OSC7_PATH%` on their own recognisance", and not try and actually implement any specific behaviour for OSC7, since OSC9;9 fills its use-case in all situations that WT _should_ care about: setting the starting directory for the new process. > > Okay maybe it is relevant to this ticket; if `WT_OSC7_PATH` defaulted to `startingDirectory` when that is a POSIX-style path, then this pattern might let us remove one of the WSL-specific hacks (at the cost of putting it explicitly in the WSL profile commandline), or at least simplify it to implicitly adding literal `--cd %WT_OSC7_PATH%` before env-var handling. > > But I still think the general idea of "Capture OSC7 and expose it as an env-var for commandlines/processes to use as they see fit" might be worth a feature request. (That would also let us close #3158 as "We're not using OSC7 for automatic CWD setting, we only support OSC9;9 for that"...) I'd happy with either OSC7 or OSC9;9 turning into an env var, and dropping WSL-specific hack. I don't totally follow the argument for why OSC9;9 was introduced vs reusing OSC7 but I'll leave that to others who've thought about it longer/harder. EDIT: I just found MangleStartingDirectoryForWSL() ... YUCK!
claunia commented 2026-01-31 05:38:58 +00:00
Author
Owner
Copy Link

@TBBle commented on GitHub (Sep 29, 2024):

It's not at all clear in the code that OSC9;9 can only refer to a Windows path? (though I am new to this codebase, I just scanned quickly)

It's actually per the spec of OSC9;9 as far as I recall. Edit: I dreamed this, apparently. The spec is literally "Inform ConEmu about shell current working directory". I have no idea if or how ConEmu deals with non-Windows paths here. Edit: It fails. ConEmu's msys/cygwin connector appears to convert paths in OSC9;9 before passing them up to ConEmu, so ConEmu users aren't habitually using cygpath/wslpath, but it works fine if they do.

The only reason it works with WSL profiles without wslpath is because WT doesn't validate the path at all, and then the existing hack to make in-WSL paths work kicks in.

If we ever implement a feature to open other profiles with the current directory then you'll need to be using wslpath if you want to open, e.g., pwsh in the same directory as your current WSL session.

Even right now, if you open a pwsh session, and run WSL inside it, without wslpath'ing your OSC9;9 path, duplicating the tab will open pwsh in your profile directory, not your last pwsh path, nor your current WSL path. fail to start pwsh. MangleStartingDirectoryForWSL will only catch the case of a ~, which PWD should never be, and otherwise lets the POSIX path through which then fails because (unless you're very lucky) there's no such directory on Windows.

So I'd strongly suggest using wslpath now to avoid future "Why doesn't it work now?" surprises.

@TBBle commented on GitHub (Sep 29, 2024): > It's not at all clear in the code that OSC9;9 can only refer to a Windows path? (though I am new to this codebase, I just scanned quickly) ~It's actually per the spec of OSC9;9 as far as I recall.~ Edit: I dreamed this, apparently. The spec is literally "[Inform ConEmu about shell current working directory](https://conemu.github.io/en/AnsiEscapeCodes.html#ConEmu_specific_OSC)". ~I have no idea if or how ConEmu deals with non-Windows paths here.~ Edit: [It fails.](https://github.com/cmderdev/cmder/issues/455#issuecomment-1446702781) ConEmu's msys/cygwin connector appears to convert paths in OSC9;9 before passing them up to ConEmu, so ConEmu users aren't habitually using cygpath/wslpath, but it works fine if they do. The only reason it works with WSL profiles without wslpath is because WT doesn't validate the path at all, and then the existing hack to make in-WSL paths work kicks in. If we ever implement a feature to open _other profiles_ with the current directory then you'll need to be using wslpath if you want to open, e.g., pwsh in the same directory as your current WSL session. Even right now, if you open a pwsh session, and run WSL inside it, without wslpath'ing your OSC9;9 path, duplicating the tab will ~~open pwsh in your profile directory, not your last pwsh path, nor your current WSL path.~~ fail to start pwsh. `MangleStartingDirectoryForWSL` will only catch the case of a `~`, which PWD should never be, and otherwise lets the POSIX path through which then fails because (unless you're very lucky) there's no such directory on Windows. So I'd strongly suggest using wslpath now to avoid future "Why doesn't it work now?" surprises.
claunia commented 2026-01-31 05:38:59 +00:00
Author
Owner
Copy Link

@TBBle commented on GitHub (Sep 29, 2024):

I don't totally follow the argument for why OSC9;9 was introduced vs reusing OSC7 but I'll leave that to others who've thought about it longer/harder.

Basically, everytime someone from the Windows world tried to implement OSC7, a bunch of corner cases showed up for POSIX paths, and we also re-learned that Windows defines the file: url differently in different places.

OSC9;9 is specific to Windows-based terminal emulators so it was easier to implement first.

@TBBle commented on GitHub (Sep 29, 2024): > I don't totally follow the argument for why OSC9;9 was introduced vs reusing OSC7 but I'll leave that to others who've thought about it longer/harder. Basically, everytime someone from the Windows world tried to implement OSC7, a bunch of corner cases showed up for POSIX paths, and we also re-learned that Windows defines the file: url differently in different places. OSC9;9 is specific to Windows-based terminal emulators so it was easier to implement first.
claunia commented 2026-01-31 05:39:00 +00:00
Author
Owner
Copy Link

@reardonia commented on GitHub (Sep 29, 2024):

So I'd strongly suggest using wslpath now to avoid future "Why doesn't it work now?" surprises.

I don't follow. This is exactly what breaks in the 'ssh' scenario, where wslpath is not available.

In any case, should I attempt to file a a feature request (to make either OSC9;9 or OSC7 info available via env var) or presume that it will implicitly follow from this discussion?

@reardonia commented on GitHub (Sep 29, 2024): > So I'd strongly suggest using wslpath now to avoid future "Why doesn't it work now?" surprises. I don't follow. This is exactly what breaks in the 'ssh' scenario, where wslpath is not available. In any case, should I attempt to file a a feature request (to make either OSC9;9 or OSC7 info available via env var) or presume that it will implicitly follow from this discussion?
claunia commented 2026-01-31 05:39:00 +00:00
Author
Owner
Copy Link

@TBBle commented on GitHub (Sep 29, 2024):

I was referring to the comment about WSL sessions apparently not needing wslpath in the OSC 9;9 script. I would strongly not recommend sending OSC9;9 back from remote SSH hosts, as that is out-of-spec; even OSC7 was intended for local-only use, but as I mentioned when someone tried to standardise it, a bunch of questions like "What do we do about SSH" appeared and the whole thing was stalled.

Anyway... yes, I'd recommend filing a feature request; that way it'll be more clearly in front of the project developers, and if nothing else, should receive feedback on better ways to achieve what you need, and/or better implementations that "Expose as env-var".

@TBBle commented on GitHub (Sep 29, 2024): I was referring to the comment about WSL sessions apparently not needing `wslpath` in the OSC 9;9 script. I would strongly _not_ recommend sending OSC9;9 back from remote SSH hosts, as that is out-of-spec; even OSC7 was intended for local-only use, but as I mentioned when someone tried to standardise it, a bunch of questions like "What do we do about SSH" appeared and the whole thing was stalled. Anyway... yes, I'd recommend filing a feature request; that way it'll be more clearly in front of the project developers, and if nothing else, should receive feedback on better ways to achieve what you need, and/or better implementations that "Expose as env-var".
claunia commented 2026-01-31 05:39:01 +00:00
Author
Owner
Copy Link

@reardonia commented on GitHub (Oct 1, 2024):

Anyway... yes, I'd recommend filing a feature request; that way it'll be more clearly in front of the project developers, and if nothing else, should receive feedback on better ways to achieve what you need, and/or better implementations that "Expose as env-var".

#17980

@reardonia commented on GitHub (Oct 1, 2024): > Anyway... yes, I'd recommend filing a feature request; that way it'll be more clearly in front of the project developers, and if nothing else, should receive feedback on better ways to achieve what you need, and/or better implementations that "Expose as env-var". #17980
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-Settings Issue-Question Product-Terminal Resolution-Answered Resolution-External
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#17316
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?