@DHowett-MSFT is correct. "startingDirectory": "~" doesn’t work for WSL shells, but this does:

  "startingDirectory": "\\\\wsl$\\Ubuntu\\home\\joe"

Hey all,

So this turned out to be a more complicated story that it seemed on the surface. There’s more information in #3547 on all the edge cases with this scenario, feel free to read that thread if you’re interested in more details.

Going forward, the official way to make this scenario work will be typing wt -d . into the explorer bar. That will tell wt to open in the current working directory. I know this isn’t ideal, but frankly it’s the only solution that still supports all the user stories we want. This functionality was added in #4023, and should be arriving in v0.9.

Thanks everyone!

I’m totally agree with @nphmuller from this comment. In my workflow there is no time to remember about -p parameter. For me behavior same like cmd, powershell, sh … is killer feature of Windows explorer. It would be nice when wt will be compatible with shuch a behavior.

I don’t see it explicitly mentioned in this thread, but adding/setting "startingDirectory": "", for any particular profile in the settings.json will cause the behavior specified in https://github.com/microsoft/terminal/pull/3547 i.e. type wt in the explorer bar and start the default terminal profile in the current explorer directory.

hopefully this makes it clearer for people arriving here by Google or whatever.

Just saw this issue, the following works fine for me for getting into the home directory for WSL:

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

no startingDirectory entry for wsl

Try "startingDirectory": "." for workaround.

see HERE for example.

@fghzxm For my personally they both are about just as important. So that doesn’t help. 😁

My main point is: Bash (WSL), cmd, PowerShell, Windows Explorer and VSCode (Explorer and VSCode via the . parameter) implemented a pattern where I could simply type the name of the executable, and it would open in the current directory. When starting via the start menu (or Run) it starts in the home directory, (or in a default view in the case on Explorer and VSCode).

I think it’d be nice if WT could also implement this widely used pattern. Using a -p parameter would work, but it would make this a bit harder the guess, and harder to use because it requires WT specific know-how.

Sorry for not coming up with a better solution. Just wanted to reiterate the point.

Just found this in the docs, seems like you can use forward slashes and not be bothered by escaping: //wsl$/Ubuntu/home/username.

//wsl$/Ubuntu-18.04/home/username for me, since I’m using Ubuntu 18.04 LTS from Microsoft Store.

@ffes You will get /mnt/c/Windows/System32 if you invoke the plain wsl command. You want wsl ~.

Just found this in the docs, seems like you can use forward slashes and not be bothered by escaping: //wsl$/Ubuntu/home/username.

As of v0.5, you’ll need "startingDirectory": null for that workaround. This was regressed unintentionally, but it wasn’t ever really a supported workaround, and we’re still hoping for a real fix, but this will work for now.

A really simple work around is add cd to the end of bashrc.

echo "cd" >> ~/.bashrc

I have a different, but connected issue. Is it somehow possible to keep the current working directory when I open a tab or split from within Windows Terminal itself?

What I mean is:

1. I run Windows Terminal
2. I navigate to D:\
3. I open a new tab.
4. The tab is opened in the default location, instead of D:\

Same thing for splits.

"commandline" : "wsl.exe -d Ubuntu-18.04", "startingDirectory" : "\\wsl$\Ubuntu\home\moose",

You’ll probably want \\\\wsl$\\Ubuntu-18.04\\home\\moose. The name after the wsl$ pseudotarget needs to match the distribution name.

+1 In version: 0.3.2171.0 startingDirectory is not respected. Strictly defaults to %USERPROFILE% where I want “~” for default wsl.exe shells.

I think we can let wt.exe have a command line option

-p "P:\ath\to\some\directory"

and use that path for the starting directory, otherwise respecting the profile settings. This way you can type wt.exe -p . and get the behavior you want. We probably should also have a look at how terminal emulators on other platforms behave in this aspect, but I think gnome-terminal always launches the shell in my home directory…

I don’t think having 2 different behaviors depending on whether the parent process is cmd.exe, explorer.exe or some other is a good thing because

• The differing behaviors are confusing to the user, and
• The user could still launch wt.exe from msys2 bash, cygwin bash or any other alternative shell of which we would have to maintain a list that can never be exhaustive.

(Plus, I guess since Start now has its own process StartMenuExperienceHost.exe, the actual parent of the processes launched from Start will be that process instead?)

I’m here from this issue https://github.com/microsoft/terminal/issues/11544

I think it’s important to make this command tool compatible with the entire command line ecosystem. In a shell, wt -d . should be replaced by wt . (like for cmd) In the navigation bar, wt should open the terminal in the current directory (like for cmd)

Oh my. Sorry for wasting everyone’s time. You can go ahead and delete this waste of space.

My profile has "commandline": "wsl.exe -d Ubuntu". I expect it to start in $HOME aka ~ and not in /mnt/c/Windows/SYSTEM32.

Know that startingDirectory is not set for this profile. That is how the profile was created when installed on my machine.

I am using the current store version: 0.2.1715.0

This must be an annoying issue, seeing how many people fail to find it and get’s repeated over and over.

😃 Maybe Windows could provide an API to solve this issue and it may be even useful to many other applications.

That’s not exactly true. The problem here is that startingDirectory is a windows path.

This way you can type wt.exe -p . and get the behavior you want.

Great solution! Maybe the the -p parameter can also be used as the default (unnamed) parameter. That way we can even use wt.exe .. Which looks like the workflow many apps use (explorer ., code .)

I don’t think having 2 different behaviors depending on whether the parent process is cmd.exe, explorer.exe or some other is a good thing because

Totally agreed. The solution you mentioned (-p) is simple and predictable.

Run: wt.reg

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\Background\shell\wt\command]
@="%LOCALAPPDATA%\Microsoft\WindowsApps\wt.exe -d ."

Sure:

// To view the default settings, hold "alt" while clicking on the "Settings" button.
// For documentation on these settings, see: https://aka.ms/terminal-documentation

{
    "$schema": "https://aka.ms/terminal-profiles-schema",

    "defaultProfile": "{58ad8b0c-3ef8-5f4d-bc6f-13e4c00f2530}",

    "alwaysShowTabs": true,
    "showTabsInTitlebar": false,

    "profiles":
    [
        {
            // Make changes here to the powershell.exe profile
            "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
            "name": "Windows PowerShell",
            "commandline": "powershell.exe",
            "hidden": false
        },
        {
            // Make changes here to the cmd.exe profile
            "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
            "name": "cmd",
            "commandline": "cmd.exe",
            "hidden": false
        },
        {
            "guid": "{58ad8b0c-3ef8-5f4d-bc6f-13e4c00f2530}",
            "hidden": false,
            "name": "Debian",
            "source": "Windows.Terminal.Wsl",

            "fontSize" : 9,
            "padding" : "0, 0, 0, 0",
            "startingDirectory" : "//wsl$/Debian/home/bogdan-barbu",
            "cursorShape" : "vintage"
        },
        {
            "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
            "hidden": false,
            "name": "Azure Cloud Shell",
            "source": "Windows.Terminal.Azure"
        }
    ],

    // Add custom color schemes to this array
    "schemes": [],

    // Add any keybinding overrides to this array.
    // To unbind a default keybinding, set the command to "unbound"
    "keybindings": []
}

None of the things proposed here work any longer.

    "startingDirectory" : "\\\\wsl$\\Debian\\home\\<linuxuser>"

which is in the default Debian profile, actually leads me to a totally different predefined path: /mnt/c/Users/<WindowsUser>. I want my Linux home directory, not my Windows home directory.

PS: I tried the full Windows path to where the Debian home directory is stored, properly escaping it, and that lead me to Debian’s root directory and no further than that.

What I am used to be doing is going through directories in total commander, when in right spot typing “cmd” or “Powershell” to open a cmd line to run some commands. The same way I used to switch between cmd, Powershell or bash. I know these are shells, and this is terminal - however, in the end, all these are “windows where you can type in commands” 😃. Need to type anything extra would make terminal work differently to how it currently works in cmd, bash or Powershell.

For the benefit of people looking like me for how this can be worked around for now: You need to remove "startingDirectory" : "%USERPROFILE%", from profiles.json and then wt will start in the directory you are in. [I have version 0.4.2382.0]

@DHowett-MSFT is correct. "startingDirectory": "~" doesn’t work for WSL shells, but this does:

  "startingDirectory": "\\\\wsl$\\Ubuntu\\home\\joe"

This workaround no longer seems to be functioning with the latest update. The issue however still remains.

(When I say latest update, I am referring to the build available via the MSFT store.)