@long-nguyenxuan

---

@PrOF-kk you’ll need to use wt -d . to get wt to start in the current working directory.

I need to disable and enable alias after latest terminal update, because it couldn’t find when running wt from explorer path input 😕

Im having this problem but its a different error and nothing in this issue solved it. I don’t have preview installed

Any ideas?

When i run from the start menu it works fine, its just when i try to run using wt.exe It also ran fine before, it started doing that a few days ago

I can reproduce with Windows Terminal 1.1.2021.0 and Windows Terminal Preview 1.2.2022.0 on Windows 10 version 2004 (OS Build 19041.388):

• If I enable the wt.exe app execution alias of Windows Terminal Preview, then wt in File Explorer starts Windows Terminal Preview. ✔
• If I enable the wt.exe app execution alias of Windows Terminal, then wt in File Explorer shows the access-denied dialog box. ❌
• If I disable both wt.exe app execution aliases, then wt in File Explorer shows the access-denied dialog box. 🙄 In this case though, I shouldn’t expect wt to work anyway.

When I install Windows Terminal Preview, AppXSvc creates the following Registry keys:

• HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe

Those Registry keys stay there when I enable or disable the wt.exe app execution aliases. They seem related to https://github.com/microsoft/terminal/issues/6748 and https://github.com/microsoft/terminal/pull/6860. If I rename the Registry keys, then the results change:

• If I enable the wt.exe app execution alias of Windows Terminal Preview, then wt in File Explorer runs Windows Terminal Preview. ✔
• If I enable the wt.exe app execution alias of Windows Terminal, then wt in File Explorer runs Windows Terminal. ✔
• If I disable both wt.exe app execution aliases, then wt in File Explorer opens http://wt/ in my Web browser. 🙄

If I disable the skype.exe app execution alias and type skype.exe in the Windows+R run box or in the File Explorer address bar, then I get a similar access-denied dialog box, so this is not specific to Windows Terminal.

If Windows needs a Registry key in App Paths, then perhaps it should keep the per-user key always synchronized with the app execution aliases, and not create the per-machine key.

I cannot reproduce in 1.1.2233.0, but Windows Terminal always opens in C:\Users\%USERNAME% directory regardless of where explorer is opened
Note: cmd.exe set as default profile

Typing wt does not work for me in Run (Start+R) or Windows Explorer, but it does work when I type wt in cmd. Disabling and enabling the alias in alias settings had no effect.

Toggling “Windows Terminal” under Application Aliases as @zadjii-msft pointed out fixed my issue of not being able to launch wt.exe.

I need to disable and enable alias after latest terminal update, because it couldn’t find when running wt from explorer path input 😕

Also experienced this from a recent update and this solution worked for me.

As explained above by Kalle, the path is defined in the registry keys for “App Paths”. There was a discrepancy where the path pointed to a previously installed version of wt C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe> when actually the app was updated so the correct path would be C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.8.1521.0_x64__8wekyb3d8bbwe>. Re-enabling wt.exe under ‘App execution aliases’ settings fixed it.

@stmax82 You might already know this, but to get the behavior you want, you can do one of:

• wt -d .
• wt --startingDirectory .
• wt new-tab -d .
• wt new-tab --startingDirectory .

These all mean exactly the same thing.

-d is an alias for -startingDirectory, and new-tab is the default argument to wt.exe, when the user does not provide an argument.

FWIW I do not see a wt.exe key under HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths, but I do see one under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths.

^^ this was quite a helpful clue, @haydenmc

I have both Windows Terminal Preview and Windows Terminal, both installed via the store.

wt -d . from the address bar in Windows Explorer was broken completely, with the same error dialog from Windows Terminal Preview in the original post. I have the preview installed, but I’m not using it at the moment. I was trying to invoke vanilla Windows Terminal.

The settings in the “App Execution Aliases” panel looked right. The one for Windows Terminal was turned on, and the one for Windows Terminal Preview was turned off.

But when I checked under
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths , and HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths,

I saw that Windows Terminal Preview was “hogging the spotlight” by having it configured under HKEY_CURRENT_USER. So, I renamed it from wt.exe to wtp.exe , just so that it wouldn’t interfere with my use of wt -d . from the Windows Explorer address bar to invoke vanilla Windows Terminal. (Windows Terminal Preview is still broken in this regard, but I just wanted to be able to get working again).

The existing entry for Windows Terminal under HKEY_LOCAL_MACHINE was working fine, so I left it where it was. I guess these are supposed to be under HKCU now?

    Hive: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
Name                           Property
----                           --------
wtp.exe                        (default) : C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.3.2382.0_x64__8wekyb3d8bbwe\wt.exe
^^ was wt.exe                  Path      : C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.3.2382.0_x64__8wekyb3d8bbwe

    Hive: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
Name                           Property
----                           --------
wt.exe                         (default) : C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.2.2381.0_x64__8wekyb3d8bbwe\wt.exe
                               Path      : C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.2.2381.0_x64__8wekyb3d8bbwe

Caveat: wt new-tab -d . is broken for me; it simply launches a new copy of Windows Terminal instead of creating a new tab in an existing instance. (Perhaps it requires a single instance for the new-tab functionality to work? Or maybe that is only available in the Preview?)

Edit: looks like @KalleOlaviNiemitalo had the analysis nailed, back at the beginning of the thread:

If Windows needs a Registry key in App Paths, then perhaps it should keep the per-user key always synchronized with the app execution aliases, and not create the per-machine key.

Maybe we should have three execution aliases: wt.exe, wtp.exe, and wtd.exe, to keep the release, preview, and dev versions from stepping on each other?

@ntindle Nope, no need. That flag is technically part of the new-tab command:

when no command is explicitly passed to wt, it assumes the command to be new-tab.