This is by design.

We have plans to support setting another application as the "default terminal" on Windows, but those plans are still very rough and in the works.

This will require an OS feature. I'm updating the title to represent the default terminal OS change.

I'm renaming this to add the [defterm] keyword to the end so that we can find it easily in searches. The words "default" and, well, "terminal" come up alarmingly often in this repository. :smile:

I am curious how ConEmu does this. Once installed, every new cmd/ps/bash window opens in ConEmu as a new tab

I am curious how ConEmu does this. Once installed, every new cmd/ps/bash window opens in ConEmu as a new tab

Same here, not sure how but hopefully Windows will be updated to support the terminal fully.

I am curious how ConEmu does this. Once installed, every new cmd/ps/bash window opens in ConEmu as a new tab

ConEmu may be (ab)using the ability to set a custom debugger for a process. I believe Process Explorer does the same to "replace" Task Manager

Process Hacker also supports “replacing” the Task Manager.

I am curious how ConEmu does this. Once installed, every new cmd/ps/bash window opens in ConEmu as a new tab

ConEmu may be (ab)using the ability to set a custom debugger for a process. I believe Process Explorer does the same to "replace" Task Manager

AFAIR, it just changes a registry key.

Whatever, ConEmu manages to do this, so MST should too.

ConEmu injects hooks (DLLs) into specific processes (such as explorer.exe or devenv.exe) to intercept the creation of new console windows under those processes. You can read more about this on the official docs: https://conemu.github.io/en/DefaultTerminal.html

As mentioned in that link, this method is purely a _hack_. It is most definitely not a viable solution for Windows Terminal.

But… it works. Having an access to whole subsystem simplifies a thing.

The difference is that Windows Terminal is an official Microsoft product, so the expectation here is that the default terminal will not be changed using an uscalable ugly hack, but be natively supported by Windows.

I don't know if this is the appropriate place to mention this however I feel it might be relevant.

For some reason right now, cmd and powershell, seemingly have abritary huge font sizes and window sizes depending on how and from where they are launched. From start menu, via explorer, via Win + R, etc.

When the new terminal becomes the default will it:

1. Have a consistent font size and window size?
2. Also be the default terminal from doing "Open Poweshell window here" etc?

Here are some examples to demonstrate what I mean.

In order, launched from a task bar shortcut, launched from "Open Powershell window here", launched from typing "powershell" in File Explorer address input (note how the default prompt seems to be different too).

It would be good if the Terminal unifies all of this. It's quite frustrating.

@lloydjatkinson thanks! It's only slightly appropriate here, but suffice it to say that:

• the Console has three (!) (and a half) different places it reads settings from
• Terminal has only one (and a half)

To answer your specific numbered points:

1. Yeah, totally, because there's only one source of truth for settings.
2. Yeah, that's what this feature is tracking. Redirecting to the Terminal any time a console window is launched for interactive use.

The default prompt just looks like it's representing that you're in a different directory. Starting powershell from the address bar in explorer does so in whatever directory you're currently viewing.

Dear Team, is this still very much down in the backlog? Now with the release of Powershell7, it raises the demand for having easier access to a modern terminal that is able to handle the correct Powershell.

1421 does only open PS5.1 at the moment and there is no official option to change this

I've spoken with Steve Lee on twitter and of course it would be benefit to promote the use of both products Terminal and Powershell on recent releases / insider releases Windows 10 clients.

@Karl-WE we’re getting v1 out the door before we start looking at the changes necessary to Windows to support the registration, enumeration and execution of alternate console hosts (or the terminals that would use them)

Since this would likely require some API support, it can probably only be done as part of a big Windows release.

Thanks Dustin for your excellent work here. I hope that this inter team effort can be communicated with the Insider and Powershell Teams, Good luck with the 1.0 release schedules. perhaps we can have this achieved for 20H2 which leaves everyone involved 9 months at least.

I hope this gets added sooner rather than later, are there any working unofficial workarounds?

Rest assured that this issue would have had hundreds of community comments making up all sorts of crazy workarounds if there were any ;)

I have a idea for some basic bat file:
run your bat file in background and then close the default cmd window

START /B  wt cmd /c yourfile.bat
exit

Rest assured that this issue would have had hundreds of community comments making up all sorts of crazy workarounds if there were any ;)

I have been starting cmd (and now powershell) from Win+R for decades, but I am painfully retraining myself to type wt instead. I guess you can teach an old dog new tricks. Slowly. 😁

This works thanks to the app execution alias wt.exe in %userprofile%\AppDataLocalMicrosoftWindowsApps

Hi team, users, since wt has now very good set of options and a preset settings json and a user defineable part which also includes the setting, which console is the default console to be opened when launching wt - I thought it would be sufficient to pick up all the rough plans (https://github.com/microsoft/terminal/issues/492#issuecomment-490092382) to pick up at least the following attempt:

Integration of Win+X.

How I _think_ you can accomplish this:

• connect with Jennifer Gentlemen and team for settings
• add a new settings item that is able to replace or update the following setting to launch wt instead powershell or cmd
• update the ADMX file accordingly so it can be set via GPO, too

• caveat: wt needs to be installed by the user

• the user can use the default console option to specify which shall be opened by default from there

like
"profiles": [ "defaultProfile": "{574e775e-4f2a-5b96-ac1e-a2962a402336}" { "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}", "hidden": false, "name": "PowerShell 7", "source": "Windows.Terminal.PowershellCore", "useAcrylic": true }, ],

Settings > Personalisation > Taskbar

"replace Win+X cmd with powershell"

Maybe it is a naive point of view of a user, yet I cannot imagine that it is possible to switch cmd to Powershell at this point for years now, but not making the small step forward to replace these two items again with wt. And yes it would make sense this way having wt with and without admin rights, as per default it is also unelevated like every other console (with few exceptions)

Can you please elaborate why this is so much work to do? It would be a beginning.

Having the choice of a default terminal application in Settings > Apps and Features > Default app - I can understand this requires more under the hood work. I double checked with NirSoft ShellExView that this can not be that easily achieved at the moment.

However changing the Win+X setting mentioned above is already something that is there.
Please mind there is even a 3rd party tool that can change the Win+X menu to anyones liking but the download source I would nowadays rather rate untrusted.

You can find the tool here but use at your own risk
Win+X Menu Editor
Created by Sergey "Happy Bulldozer" Tkachenko
http://winaero.com
This software uses the hashlnk tool source code
hashlnk was created by Rafael Rivera
http://www.withinwindows.com/

Hope I am allowed to post this reference otherwise please remove it. If I may upload the app as a zip or Onedrive please let me know. There is no hint that it is not allowed to mirror it elsewhere.

p.s. I've tried myself to Add wt into a new group in Win+X menu but for some unclear reason it fails to do so. Permissions seem about right. I can add any file as a link except things from
%localappdata%MicrosoftWindowsApps (even with full path).

I am curious what prevents this by design. It seems because the apps there are 0 kb sized files and some kind of symlink? In Task Manager you also cannot "open the location" of a wt process. I suspect this is the nature of app virtualization of MS apps. Also applies to other like Edge Chromium, notepadS etc.

Given this information and circumstances I might now grasp why it is so hard to accomplish this change. You cannot access it from explorer, but you can launch it from Win+R / search. How weird.

You can't add wt.exe directly, as it's not a "real file", but if you create a shortcut to wt.exe, the tool will be able to add it and it'll work just fine.

You can read more about it here: https://www.hanselman.com/blog/TotallyUnsupportedHacksAddWindowsTerminalToTheWinXShortcutMenu.aspx

If I understand the function of WinX correctly Windows does not do links by path only, probably to prevent spoofing but also generating a hash of the file. Since all "apps" have zero filesize the "cannot open" might be due to not being able to generate the hash, probably not because not being able to access / read it.

Thanks for the reference thlac @shanselman this makes it even harder to understand why there is no official way. Ofc having a shortcut to a file exposes a risk of tampering it, what seems to contradict the original design idea of WinX not being easily tampered.
The risk is infact that PUA / malware could change targets in this menu.

@Karl-WE Just wanted to make sure everyone is on the same page here. Windows Terminal is a terminal/console application - not a shell. Cmd and PowerShell are shells. (See also: https://www.hanselman.com/blog/WhatsTheDifferenceBetweenAConsoleATerminalAndAShell.aspx)

So the Win+X setting is (IMHO) irrelevant for this issue (as it just determines the shell, not the terminal application).

I understand your definition. At the end, given the many same requests, WinX does help to make Windows Terminal

• more prominent, which can only aid its success and spread and ultimately honor the work spent.

• help users to make their favourite default shell more accessible.
  Which might be not cmd or PoSh 5.1 as configurable at the moment.

Seeing it in this light, I still agree with your noted difference but in the end the goal is to help making a shell easier to access while having the better features of terminal compared to the default console.

@nu8 you’ll probably agree that “replacing your system conhost with the version of conhost built out of this repository” and “having Windows launch an instance of Terminal automatically” are vastly different things ;)

This repository hosts both the console host _and_ the Terminal. One builds on the other, but they are certainly not the same.

@nu8 given the vast amount of things @DHowett has to review and triage sometimes there maybe differences. As you quoted it is clear that 492 in timeline came before 1817 and things can change.
it would be more irritating if he posted it other way around. But however:

the good news is: it is on the schedule, no longer in the backlog

see

1 | Default terminal | If a command-line application is spawned, it should open in Windows Terminal (if installed) or your preferred terminal
Issue: #492
Spec: #2080

source: https://github.com/microsoft/terminal/blob/master/doc/terminal-v2-roadmap.md

@DHowett thank you for your work around here, I have a small question:
Do you think we could expect this to roll out in 20h2 or 21h1 windows' update? Are you aware of any internal work (on OS level) going in this direction?
I understand that plans may change, but I'm still curious :)

We're the team that would have to do the OS-level work to enable this feature, so I'd be very surprised if we _weren't_ aware of work being done to enable this.

We're still just getting past the 1.0 release of the Terminal, so we haven't really gotten a start on this quite yet. I'd say it's unlikely to land in 20H2 or 21H1, considering we'd probably have to have the feature done (or at least prototyped) by now to get it in to either of those releases.

i wonder what will come first - defterm setting or full gpu acceleration support in WSL2, at which point we could just use native linux terminals instead, at least for development that can be virtualized

Because this issue has so many subscribers, I'm going to lock it.
If you have something to contribute that will impact the engineering direction for this feature, please e-mail me at the address on my GitHub profile.