Add support for wt.exe to run commands in an existing Terminal Window #6289

@zadjii-msft commented on GitHub (Feb 7, 2020):

This was briefly mentioned in this spec

Future considerations

These are some additional argument ideas which are dependent on other features
that might not land for a long time. These features were still considered as a
part of the design of this solution, though their implementation is purely
hypothetical for the time being.

Instead of launching a new Windows Terminal window, attach this new
terminal to an existing one. This would require the work outlined in
[#2080], so support a "manager" process that could coordinate sessions
like this.

This would be something like wt --session [some-session-id] [commands], where --session [some-session-id] would tell us that
[more-commands] are intended for the given other session/window.
That way, you could open a new tab in another window with wt --session 0 cmd.exe (for example).

list-sessions: A command to display all the active Windows terminal
instances and their session ID's, in a way compatible with the above
command. Again, heavily dependent upon the implementation of [#2080].

Which yea is part of #2080, but I don't think has it's own issue.

@zadjii-msft commented on GitHub (Feb 7, 2020): This was briefly mentioned in [this spec](https://github.com/microsoft/terminal/blob/master/doc/specs/%23607%20-%20Commandline%20Arguments%20for%20the%20Windows%20Terminal.md#L667-L684) > ## Future considerations > * These are some additional argument ideas which are dependent on other features that might not land for a long time. These features were still considered as a part of the design of this solution, though their implementation is purely hypothetical for the time being. > * Instead of launching a new Windows Terminal window, attach this new terminal to an existing one. This would require the work outlined in [#2080], so support a "manager" process that could coordinate sessions like this. > - This would be something like `wt --session [some-session-id] [commands]`, where `--session [some-session-id]` would tell us that `[more-commands]` are intended for the given other session/window. That way, you could open a new tab in another window with `wt --session 0 cmd.exe` (for example). > * `list-sessions`: A command to display all the active Windows terminal instances and their session ID's, in a way compatible with the above command. Again, heavily dependent upon the implementation of [#2080]. Which yea is part of #2080, but I don't think has it's own issue.

claunia commented

@Rumbah2 commented on GitHub (Feb 14, 2020):

Wow, I was just thinking about "starting a new program/task in any existing windows terminal window" or a "single instance mode" to populate a WT window with multiple tasks via CLI would be great.
But something like sessions would be even better and more flexible.

But I admit that I'd prefer a "quick and dirty" single instance mode in the near future over a flexible session management in the distant future (as I could use it sooner than later).

@Rumbah2 commented on GitHub (Feb 14, 2020): Wow, I was just thinking about "starting a new program/task in any existing windows terminal window" or a "single instance mode" to populate a WT window with multiple tasks via CLI would be great. But something like sessions would be even better and more flexible. But I admit that I'd prefer a "quick and dirty" single instance mode in the near future over a flexible session management in the distant future (as I could use it sooner than later).

claunia commented

@nmyron commented on GitHub (Apr 24, 2020):

So, I wanted to report an issue I've found that seems to be the same as "https://github.com/microsoft/terminal/issues/4942" - it was closed as a duplicate of this issue, but I don't believe that it truly is. Because the docs say (quoted from one of the closure remarks on the other issue)

The docs are correct here:

Opens a new tab with the given customizations. On its first invocation, also opens a new window. Subsequent new-tab commands will all open new tabs in the same window.

However, say I go to start and type "wt", and get myself a new console. Then I type "wt new-tab "PowerShell"", that will start a second wt window with the desired tab, while waiting at the first window for me to close the new window (process starts and the terminal is waiting for process end). So I can't go back to that "first invocation" to issue additional commands. And if I go to the second-launched WT console, and again type in wt.exe new-tab, I will get a third new window, not a second new tab in the already-launched second session. And in no way have I found yet with the command line inputs to split a pane in an existing window. Every time I issue split-pane it behaves the same as new-tab, and I get an additional window.

Replicate:

Start > wt (opens new Windows Terminal window)
wt.exe new-tab (will start a second new Windows Terminal window. If your first terminal was running PowerShell, that session is now waiting for this second new window to close - trying to "start-process" with "-nonewwindow" does not help)
Since first terminal window is now waiting for second to close, we cannot give additional commands there, going to the second window and issuing "wt new-tab" gets a third window. Trying "wt split-pane -H -P "PowerShell" in any existing window, also, does not add a split pane in any current window, it opens yet another window with the split-pane settings requested.

Because of this behavior, at this point, you cannot go back to the initial processor to issue additional WT commands. And if you go to the secondly-launched terminal window, and issue again wt new-tab, you'll get a third new window, and a second window waiting on the third to close.

I tried also starting with Command Prompt. It will start a new window, and will NOT wait for that window to close. So I AM able to return to that initial processor to try issuing additional commands. But, they behave the same. Additional new-tab commands bring new windows, not just new tabs in existing windows.

So I would pose here that as described in the closed issue your "new-tab" and "split-pane" features are operating entirely contrary to their documented conditions. And contrary to your closure remarks on the above-linked issue, it and my comment here I don't believe to be a dupe of this feature request, but an ask to make the feature behave as described in your documentation. That would make this not a feature request but a bug fix. As either the existing feature's behavior is incorrect, or the document is not describing it's expected behavior correctly. By reading your document, I expect that the first time I issue "wt new-tab" I will get a new window. And every subsequent time I issue this same command, it will open in an already-existing window as this is what you tell us it will do right now per the quote from the doc above, and it does not do this that I can verify in any way or make happen whatsoever.

Thanks!

Nathan M

@nmyron commented on GitHub (Apr 24, 2020): So, I wanted to report an issue I've found that seems to be the same as "https://github.com/microsoft/terminal/issues/4942" - it was closed as a duplicate of this issue, but I don't believe that it truly is. Because the docs say (quoted from one of the closure remarks on the other issue) > The docs are correct here: > > Opens a new tab with the given customizations. On its first invocation, also opens a new window. Subsequent new-tab commands will all open new tabs in the same window. However, say I go to start and type "wt", and get myself a new console. Then I type "wt new-tab "PowerShell"", that will start a second wt window with the desired tab, while waiting at the first window for me to close the new window (process starts and the terminal is waiting for process end). So I can't go back to that "first invocation" to issue additional commands. And if I go to the second-launched WT console, and again type in wt.exe new-tab, I will get a third new window, not a second new tab in the already-launched second session. And in no way have I found yet with the command line inputs to split a pane in an existing window. Every time I issue split-pane it behaves the same as new-tab, and I get an additional window. Replicate: Start > wt (opens new Windows Terminal window) wt.exe new-tab (will start a second new Windows Terminal window. If your first terminal was running PowerShell, that session is now waiting for this second new window to close - trying to "start-process" with "-nonewwindow" does not help) Since first terminal window is now waiting for second to close, we cannot give additional commands there, going to the second window and issuing "wt new-tab" gets a third window. Trying "wt split-pane -H -P "PowerShell" in any existing window, also, does not add a split pane in any current window, it opens yet another window with the split-pane settings requested. Because of this behavior, at this point, you cannot go back to the initial processor to issue additional WT commands. And if you go to the secondly-launched terminal window, and issue again wt new-tab, you'll get a third new window, and a second window waiting on the third to close. I tried also starting with Command Prompt. It will start a new window, and will NOT wait for that window to close. So I AM able to return to that initial processor to try issuing additional commands. But, they behave the same. Additional new-tab commands bring new windows, not just new tabs in existing windows. So I would pose here that as described in the closed issue your "new-tab" and "split-pane" features are operating entirely contrary to their documented conditions. And contrary to your closure remarks on the above-linked issue, it and my comment here I don't believe to be a dupe of this feature request, but an ask to make the feature behave as described in your documentation. That would make this not a feature request but a bug fix. As either the existing feature's behavior is incorrect, or the document is not describing it's expected behavior correctly. By reading your document, I expect that the first time I issue "wt new-tab" I will get a new window. And every subsequent time I issue this same command, it will open in an already-existing window as this is what you tell us it will do right now per the quote from the doc above, and it does not do this that I can verify in any way or make happen whatsoever. Thanks! Nathan M

claunia commented

@zadjii-msft commented on GitHub (Apr 24, 2020):

Hey so I literally just went and updated the docs on this. You can check out the PR here.

Basically, every time you run wt, it's going to create a new window first. Always. This thread right here is the thread tracking adding support to allow the user to say something like wt --inTheCurrentWindow split-pane.

These subcommands are all supposed to run as a single commandline invocation. wt new-tab ; split-pane ; new-tab will open one window with two tabs, and the first tab has a split in it. As called out in the spec:

Future considerations

These are some additional argument ideas which are dependent on other features
that might not land for a long time. These features were still considered as a
part of the design of this solution, though their implementation is purely
hypothetical for the time being.

Instead of launching a new Windows Terminal window, attach this new
terminal to an existing one. This would require the work outlined in
[#2080], so support a "manager" process that could coordinate sessions
like this.

This would be something like wt --session [some-session-id] [commands], where --session [some-session-id] would tell us that
[more-commands] are intended for the given other session/window.
That way, you could open a new tab in another window with wt --session 0 cmd.exe (for example).

RE: powershell waiting for a WT window to close - you'd probably be interested in this section of the UsingCommandlineArguments doc that was also recently added.

@zadjii-msft commented on GitHub (Apr 24, 2020): Hey so I literally just went and updated the docs on this. You can check out the PR [here](https://github.com/microsoft/terminal/pull/5448/files). Basically, every time you run `wt`, it's going to create a new window first. Always. This thread right here is the thread tracking adding support to allow the user to say something like `wt --inTheCurrentWindow split-pane`. These subcommands are all supposed to run as a _single_ commandline invocation. `wt new-tab ; split-pane ; new-tab` will open _one_ window with two tabs, and the first tab has a split in it. As called out in the spec: > ## Future considerations > > * These are some additional argument ideas which are dependent on other features > that might not land for a long time. These features were still considered as a > part of the design of this solution, though their implementation is purely > hypothetical for the time being. > * Instead of launching a new Windows Terminal window, attach this new > terminal to an existing one. This would require the work outlined in > [#2080], so support a "manager" process that could coordinate sessions > like this. > - This would be something like `wt --session [some-session-id] > [commands]`, where `--session [some-session-id]` would tell us that > `[more-commands]` are intended for the given other session/window. > That way, you could open a new tab in another window with `wt --session > 0 cmd.exe` (for example). <hr> RE: powershell waiting for a WT window to close - you'd probably be interested in [this section](https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingCommandlineArguments.md#using-multiple-commands-from-powershell) of the `UsingCommandlineArguments` doc that was also recently added.

claunia commented

@nmyron commented on GitHub (Apr 24, 2020):

Awesome! Thanks a bunch!

So, in the current iteration, there's no way in an existing window to split a pane into a new command processor? For example, say I wanted to in my existing powershell window, split-pane and bring up an ubuntu prompt in the horizontal space below? I'd have to chain those commands up to build a new window at command line, essentially?

@nmyron commented on GitHub (Apr 24, 2020): Awesome! Thanks a bunch! So, in the current iteration, there's no way in an existing window to split a pane into a new command processor? For example, say I wanted to in my existing powershell window, split-pane and bring up an ubuntu prompt in the horizontal space below? I'd have to chain those commands up to build a new window at command line, essentially?

claunia commented

@zadjii-msft commented on GitHub (Apr 24, 2020):

@nmyron that's correct. You can always just use a keybinding to split a pane, but if you'd like to do it at the commandline, you'll have to be patient ☺️

@zadjii-msft commented on GitHub (Apr 24, 2020): @nmyron that's correct. You can always just use a [keybinding ](https://github.com/microsoft/terminal/blob/master/src/cascadia/TerminalApp/defaults.json#L309-L310)to split a pane, but if you'd like to do it at the commandline, you'll have to be patient ☺️

claunia commented

@nmyron commented on GitHub (Apr 24, 2020):

Yes I have keybindings to do a split-pane, but I've yet to figure out how to split a pane into a particular processor via keybindings.

Edit - had to dig down in the docs a bit. Found the definitions for split-pane and new-tab in the Settings Schema doc. That got me where I needed to be I think.

Similar to the below suggestion, I copied the "auto-split" keybinding to create the below to launch Ubuntu in an auto-split pane. Thanks all

{ "command": { "action": "splitPane", "split": "auto", "profile": "Ubuntu" }, "keys": "ctrl+shift+d" }

@nmyron commented on GitHub (Apr 24, 2020): Yes I have keybindings to do a split-pane, but I've yet to figure out how to split a pane into a particular processor via keybindings. Edit - had to dig down in the docs a bit. Found the definitions for split-pane and new-tab in the Settings Schema doc. That got me where I needed to be I think. Similar to the below suggestion, I copied the "auto-split" keybinding to create the below to launch Ubuntu in an auto-split pane. Thanks all `{ "command": { "action": "splitPane", "split": "auto", "profile": "Ubuntu" }, "keys": "ctrl+shift+d" }`

claunia commented

@zadjii-msft commented on GitHub (Apr 24, 2020):

You can actually do something like

{ "command": { "action": "splitPane", "split": "vertical", "commandline": "powershell.exe" }, "keys": "alt+shift+plus" },

and that'll open your default profile, but with the commandline "powershell.exe" as opposed to whatever the profile's usual commandline is

@zadjii-msft commented on GitHub (Apr 24, 2020): You can actually do something like ```json { "command": { "action": "splitPane", "split": "vertical", "commandline": "powershell.exe" }, "keys": "alt+shift+plus" }, ``` and that'll open your default profile, but with the commandline "powershell.exe" as opposed to whatever the profile's usual `commandline` is

claunia commented

@FallenGameR commented on GitHub (May 13, 2020):

Here is my feedback about this requested feature. I want to do something like console fork - to start a new pwsh session on a new tab, but I'd like it to have the same current folder $pwd. Right now when I'm starting a new pwsh tab the Windows Terminal takes some hardcoded initial folder location. If I specify it to use %__CD__% instead, it doesn't pick up any changes to $pwd anyway. Even if I change [Environment]::CurrentFolder new pwsh session doesn't pick it up.

So I was hoping I could make a workaround script that would start wt.exe passing it working directory = $pwd and argument to open new tab in the same window. And I just found this thread.

Could this new feature allow my use case as well?

@FallenGameR commented on GitHub (May 13, 2020): Here is my feedback about this requested feature. I want to do something like console fork - to start a new pwsh session on a new tab, but I'd like it to have the same current folder ```$pwd```. Right now when I'm starting a new pwsh tab the Windows Terminal takes some hardcoded initial folder location. If I specify it to use ```%__CD__%``` instead, it doesn't pick up any changes to ```$pwd``` anyway. Even if I change ```[Environment]::CurrentFolder``` new pwsh session doesn't pick it up. So I was hoping I could make a workaround script that would start wt.exe passing it working directory = ```$pwd``` and argument to open new tab in the same window. And I just found this thread. Could this new feature allow my use case as well?

claunia commented

@zadjii-msft commented on GitHub (May 13, 2020):

@FallenGameR What you're looking for is tracked by #3158

@zadjii-msft commented on GitHub (May 13, 2020): @FallenGameR What you're looking for is tracked by #3158

claunia commented

@lfr commented on GitHub (May 14, 2020):

@zadjii-msft it seems @FallenGameR is asking for a command line (wt.exe) solution while #3158 seems to be solely about the CTR+T key combination unless I'm mistaken.

@lfr commented on GitHub (May 14, 2020): @zadjii-msft it seems @FallenGameR is asking for a command line (wt.exe) solution while #3158 seems to be solely about the CTR+T key combination unless I'm mistaken.

claunia commented

@FallenGameR commented on GitHub (May 14, 2020):

My ask can be implemented in several ways. I don't really have a preference, as long as some solution exists. As of now it looks like wt.exe is not your regular process and calling it has some quirks - e.g. Start-Process wt.exe -Verb RunAs don't work.

But in case wt.exe would behave like a normal callable process and new-tab --inCurrentTerminal was implemented, that would actually do the trick for me. I can script around that. Plus such kind of implementation doesn't seem to require some protocol agreement across third party terminal implementations.

@FallenGameR commented on GitHub (May 14, 2020): My ask can be implemented in several ways. I don't really have a preference, as long as some solution exists. As of now it looks like wt.exe is not your regular process and calling it has some quirks - e.g. ```Start-Process wt.exe -Verb RunAs``` don't work. But in case wt.exe would behave like a normal callable process and ```new-tab --inCurrentTerminal``` was implemented, that would actually do the trick for me. I can script around that. Plus such kind of implementation doesn't seem to require some protocol agreement across third party terminal implementations.

claunia commented

@hd321kbps commented on GitHub (May 30, 2020):

I have been waiting for this feature for a long time. She is necessary.
Cool, if the terminal can be run with administrator rights from any desired folder.

@hd321kbps commented on GitHub (May 30, 2020): I have been waiting for this feature for a long time. She is necessary. Cool, if the terminal can be run with administrator rights from any desired folder.

claunia commented

@mreymann commented on GitHub (Sep 18, 2020):

This would be exactly what I need although I could maybe script my way around this issue with AutoIt. Still would make my life easier.
When can we expect this feature to arrive via Windows Update?

@mreymann commented on GitHub (Sep 18, 2020): This would be exactly what I need although I could maybe script my way around this issue with AutoIt. Still would make my life easier. When can we expect this feature to arrive via Windows Update?

claunia commented

@zadjii-msft commented on GitHub (Sep 18, 2020):

@mreymann well, this feature hasn't been implemented yet, so certainly not for a while. It gets a mention in the spec in #7240, but a spec is still a long ways from an implementation.

I'd follow this issue for updates. When we get around to implementing this, we'll close this issue.

@zadjii-msft commented on GitHub (Sep 18, 2020): @mreymann well, this feature hasn't been implemented yet, so certainly not for a while. It gets a mention in the spec in #7240, but a spec is still a long ways from an implementation. I'd follow _this issue_ for updates. When we get around to implementing this, we'll close this issue.

claunia commented

@bmaehr commented on GitHub (Sep 25, 2020):

In fact my stupid guess was, that wt new-tab should exactly this, but it open every time a new window.

This is especially annoying when using the "Open in Windows Terminal" - every time a new window.

@bmaehr commented on GitHub (Sep 25, 2020): In fact my stupid guess was, that `wt new-tab` should exactly this, but it open every time a new window. This is especially annoying when using the "Open in Windows Terminal" - every time a new window.

claunia commented

@FireEmerald commented on GitHub (Oct 20, 2020):

A multi-tab terminal, without the ability to open a new tab in a running instance of the terminal from outside and no option to move tabs between terminal instances is like a wheel with four edges 🙄

@FireEmerald commented on GitHub (Oct 20, 2020): A multi-tab terminal, without the ability to open a new tab in a running instance of the terminal from outside and no option to move tabs between terminal instances is like a wheel with four edges 🙄

claunia commented

@xcme commented on GitHub (Oct 31, 2020):

Guys, is there some progress or news? I can't sleep well because I'm still waiting for this feature. Every day I open this page, see it still "Open" and get disappointed. All the features this application has are completely useless without this main one.

@xcme commented on GitHub (Oct 31, 2020): Guys, is there some progress or news? I can't sleep well because I'm still waiting for this feature. Every day I open this page, see it still "Open" and get disappointed. All the features this application has are completely useless without this main one.

claunia commented

@GoodClover commented on GitHub (Oct 31, 2020):

This would be brilliant working with vscode as having it spawn a new window is annoying as I have to re-dock it to the side of my screen everytime I start the debugger.

I'm the same with @bmaehr in that I assumed nt/new-tab would do this already.

Browsers do this all the time, so it can't be so hard /s

@GoodClover commented on GitHub (Oct 31, 2020): This would be brilliant working with vscode as having it spawn a new window is annoying as I have to re-dock it to the side of my screen everytime I start the debugger. I'm the same with @bmaehr in that I assumed `nt`/`new-tab` would do this already. Browsers do this all the time, so it can't be so hard /s

claunia commented

@zadjii-msft commented on GitHub (Nov 2, 2020):

@xcme The last branch I pushed to is literally the spec for this feature. It's probably 50% covered by the spec in #7240, and 50% covered by the one I'm working on now. So we'd appreciate patience while we work on hammering out the design, and feedback on the spec (once it's out for review).

@zadjii-msft commented on GitHub (Nov 2, 2020): @xcme The [last branch I pushed to ](https://github.com/microsoft/terminal/tree/dev/migrie/s/4472-window-management) is literally the spec for this feature. It's probably 50% covered by the spec in #7240, and 50% covered by the one I'm working on now. So we'd appreciate _patience_ while we work on hammering out the design, and feedback on the spec (once it's out for review).

claunia commented

@zadjii-msft commented on GitHub (Nov 2, 2020):

To all the folks following this issue losing sleep waiting for updates, the spec is out for review. You may resume losing sleep over (whatever previous thing kept you up at night).

@zadjii-msft commented on GitHub (Nov 2, 2020): To all the folks following this issue losing sleep waiting for updates, _[the spec is out for review](https://github.com/microsoft/terminal/pull/8135)_. You may resume losing sleep over (whatever previous thing kept you up at night).

claunia commented

@ralaul commented on GitHub (Dec 1, 2020):

Could this also be used to redirect consoles spawned by AllocConsole() API? Currently, when I need many of them, I have a screen full of cmd windows, which could be easily cleaned up by this terminal. I need to see the title of each console spawned in grid view though.

@ralaul commented on GitHub (Dec 1, 2020): Could this also be used to redirect consoles spawned by AllocConsole() API? Currently, when I need many of them, I have a screen full of cmd windows, which could be easily cleaned up by this terminal. I need to see the title of each console spawned in grid view though.

claunia commented

@zadjii-msft commented on GitHub (Dec 1, 2020):

@ralaul What you're looking for will actually be covered better by #492. That issue covers setting an application as the default terminal emulator on Windows, which should cause AllocConsole calls to spawn that application as a window instead of the vintage console.

@zadjii-msft commented on GitHub (Dec 1, 2020): @ralaul What you're looking for will actually be covered better by #492. That issue covers setting an application as the default terminal emulator on Windows, which should cause `AllocConsole` calls to spawn that application as a window instead of the vintage console.

claunia commented

@luxzg commented on GitHub (Dec 4, 2020):

I have a kind of a suggestion that may solve at least some of the issues mentioned above, and in related issues and docs. Why not have a command-bar like we have eg in VSCode. It can be hidden by default, but have a keybinding to trigger it, then write in that command box something like new-tab -p MyProfile No need to invoke "wt" again at all, simply send the command via this command box. It woud then trigger same thing that keybinding triggers, but it offers more flexibility, as we can't prepare hundreds of keybindings for every occasion, and we CAN type a slightly different command in this "run box" inside a working WT session.

This does NOT solve opening tab from 3rd party, like from Visual Studio. But it does solve managing tabs and panes from within the already running wt session.

Edit: not to spam active thread, tnx people, I didn't know it existed blush, was looking for it but couldn't find it, so I thought such feature didn't exist already

@luxzg commented on GitHub (Dec 4, 2020): I have a kind of a suggestion that may solve at least some of the issues mentioned above, and in related issues and docs. Why not have a command-bar like we have eg in VSCode. It can be hidden by default, but have a keybinding to trigger it, then write in that command box something like `new-tab -p MyProfile` No need to invoke "wt" again at all, simply send the command via this command box. It woud then trigger same thing that keybinding triggers, but it offers more flexibility, as we can't prepare hundreds of keybindings for every occasion, and we CAN type a slightly different command in this "run box" inside a working WT session. This does NOT solve opening tab from 3rd party, like from Visual Studio. But it does solve managing tabs and panes from within the already running wt session. Edit: not to spam active thread, tnx people, I didn't know it existed *blush*, was looking for it but couldn't find it, so I thought such feature didn't exist already

claunia commented

@pfmoore commented on GitHub (Dec 4, 2020):

It already exists, as Ctrl-Shift-P (I just found this myself recently).

@pfmoore commented on GitHub (Dec 4, 2020): It already exists, as Ctrl-Shift-P (I just found this myself recently).

claunia commented

@Don-Vito commented on GitHub (Dec 4, 2020):

I have a kind of a suggestion that may solve at least some of the issues mentioned above, and in related issues and docs. Why not have a command-bar like we have eg in VSCode. It can be hidden by default, but have a keybinding to trigger it, then write in that command box something like new-tab -p MyProfile No need to invoke "wt" again at all, simply send the command via this command box. It woud then trigger same thing that keybinding triggers, but it offers more flexibility, as we can't prepare hundreds of keybindings for every occasion, and we CAN type a slightly different command in this "run box" inside a working WT session.

This does NOT solve opening tab from 3rd party, like from Visual Studio. But it does solve managing tabs and panes from within the already running wt session.

@luxzg - what you are describing is a command line mode of command palette - you can read more about it here: https://docs.microsoft.com/en-us/windows/terminal/command-palette#command-line-mode

@Don-Vito commented on GitHub (Dec 4, 2020): > I have a kind of a suggestion that may solve at least some of the issues mentioned above, and in related issues and docs. Why not have a command-bar like we have eg in VSCode. It can be hidden by default, but have a keybinding to trigger it, then write in that command box something like `new-tab -p MyProfile` No need to invoke "wt" again at all, simply send the command via this command box. It woud then trigger same thing that keybinding triggers, but it offers more flexibility, as we can't prepare hundreds of keybindings for every occasion, and we CAN type a slightly different command in this "run box" inside a working WT session. > > This does NOT solve opening tab from 3rd party, like from Visual Studio. But it does solve managing tabs and panes from within the already running wt session. @luxzg - what you are describing is a command line mode of command palette - you can read more about it here: https://docs.microsoft.com/en-us/windows/terminal/command-palette#command-line-mode

claunia commented

@cadayton commented on GitHub (Dec 17, 2020):

Well I couldn't wait, so I rolled my own solution. See https://cadayton.keybase.pub/PSGallery/Scripts/psConsole.html

At work I have over 537 different potential login combinations of ssh/psremote/web interfaces. So I don't see a hierarchical menu system being useful at this scale.

@cadayton commented on GitHub (Dec 17, 2020): Well I couldn't wait, so I rolled my own solution. See https://cadayton.keybase.pub/PSGallery/Scripts/psConsole.html At work I have over 537 different potential login combinations of ssh/psremote/web interfaces. So I don't see a hierarchical menu system being useful at this scale.

claunia commented

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

Checklist of work that needs to be done, taken from TODOs in the code in the current branch:

Peasant windows need to raise the WindowActivated event when they're activated
Peasant needs to get it's CWD and pass that to the Monarch in ProposeCommandline
When a peasant is handling a commandline, switch to the provided CWD before running the commandline, then pop back to the starting one.
Monarch::ProposeCommandline needs to return a structure of { shouldCreateWindow: bool, givenID: optional<uint> } (names will come in a follow-up)
The monarch needs a better way of knowing who to default to before the first window is activated. Currently, it just uses "the first peasant in the map" and that's wrong. We need to somehow tell the monarch which peasant they are when they're elected
Add tracelogging to pretty much every part of the election, commandline proposal and handling
Add a common header in src/inc/ for windowing constants, like UseNewWindow=-1; UseCurrentWindow=0; etc. It needs to be there, so both remoting.dll, TerminalApp and WindowsTerminal can all reference it.
If we fail to open the monarch, then they don't exist anymore! Go straight to an election.
At any point in all this, the current monarch might die. We go straight to a new election, right?
~~if the targeted peasant fails to execute the commandline, we should create our own window to display the message box.~~
- Turns out, this was unnecessary
Tests on tests on tests
Open three windows, close the first (the monarch). The focus should automatically move to the third, from the windows shell. In that window, wt -w 0 does not work right.
Convert Monarch::SetMostRecentPeasant to Monarch::HandleActivatePeasant, and have the WindowManager pass in args that it gets from Peasant::GetLastActivatedArgs() (if the manager has a peasant).

Punted to a follow-up

Actually use WT_SESSION to resolve the "current window", not just the MRU window
Actually use the virtual desktop. That might be doable with

        auto manager = winrt::create_instance<IVirtualDesktopManager>(__uuidof(VirtualDesktopManager));
        if (manager)
        {
            manager->GetWindowDesktopId();
        }

Just trying to keep track of all the TODOs I have scattered and which ones are relevant to this feature, vs other parts of projects/5.

@zadjii-msft commented on GitHub (Jan 6, 2021): Checklist of work that needs to be done, taken from TODOs in the code in the current branch: * [x] Peasant windows need to raise the `WindowActivated` event when they're activated * [x] Peasant needs to get it's CWD and pass that to the Monarch in `ProposeCommandline` * [x] When a peasant is handling a commandline, switch to the provided CWD before running the commandline, then pop back to the starting one. * [x] `Monarch::ProposeCommandline` needs to return a structure of `{ shouldCreateWindow: bool, givenID: optional<uint> }` (names will come in a follow-up) * [x] The monarch needs a better way of knowing who to default to before the first window is activated. Currently, it just uses "the first peasant in the map" and that's _wrong_. We need to somehow tell the monarch which peasant they are when they're elected * [x] Add tracelogging to pretty much every part of the election, commandline proposal and handling * [ ] Add a common header in `src/inc/` for windowing constants, like `UseNewWindow=-1; UseCurrentWindow=0;` etc. It needs to be there, so both `remoting.dll`, `TerminalApp` and `WindowsTerminal` can all reference it. * [x] If we fail to open the monarch, then they don't exist anymore! Go straight to an election. * [x] At any point in all this, the current monarch might die. We go straight to a new election, right? * [x] ~if the targeted peasant fails to execute the commandline, we should create our own window to display the message box.~ - Turns out, this was unnecessary * [x] Tests on tests on tests * [x] Open three windows, close the first (the monarch). The focus should automatically move to the third, from the windows shell. In that window, `wt -w 0` does not work right. * [x] Convert `Monarch::SetMostRecentPeasant` to `Monarch::HandleActivatePeasant`, and have the WindowManager pass in args that it gets from `Peasant::GetLastActivatedArgs()` (if the manager has a peasant). Punted to a follow-up * [ ] Actually use `WT_SESSION` to resolve the "current window", not just the MRU window * [ ] Actually use the virtual desktop. That might be doable with ```c++ auto manager = winrt::create_instance<IVirtualDesktopManager>(__uuidof(VirtualDesktopManager)); if (manager) { manager->GetWindowDesktopId(); } ``` Just trying to keep track of all the TODOs I have scattered and which ones are relevant to this feature, vs other parts of projects/5.

claunia commented

@ChrisStavPlacecube commented on GitHub (Jan 6, 2021):

When a peasant is handling a commandline, switch to the provided CWD before running the commandline, then pop back to the starting one.

Is the use of "peasant" a technical synonym for "user", i'm lost. 😁

@ChrisStavPlacecube commented on GitHub (Jan 6, 2021): > * When a peasant is handling a commandline, switch to the provided CWD before running the commandline, then pop back to the starting one. Is the use of "peasant" a technical synonym for "user", i'm lost. 😁

claunia commented

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

Nope, that's a reference to an implementation detail. You can refer to #5000, #7240, #8135, #8171, #8607 for more details.

@zadjii-msft commented on GitHub (Jan 6, 2021): Nope, that's a reference to an implementation detail. You can refer to #5000, #7240, #8135, #8171, #8607 for more details.

claunia commented

@oising commented on GitHub (Jan 6, 2021):

When a peasant is handling a commandline, switch to the provided CWD before running the commandline, then pop back to the starting one.

Is the use of "peasant" a technical synonym for "user", i'm lost. 😁

We also elect monarchs... it's best to not think too hard ;)

@oising commented on GitHub (Jan 6, 2021): > > * When a peasant is handling a commandline, switch to the provided CWD before running the commandline, then pop back to the starting one. > > Is the use of "peasant" a technical synonym for "user", i'm lost. 😁 We also elect monarchs... it's best to not think too hard ;)

claunia commented

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

Just a taste:

@zadjii-msft commented on GitHub (Jan 7, 2021): Just a taste: ![window-management-000](https://user-images.githubusercontent.com/18356694/103932910-25199380-50e8-11eb-97e3-594a31da62d2.gif)

claunia commented

@DHowett commented on GitHub (Jan 7, 2021):

sweet

@DHowett commented on GitHub (Jan 7, 2021): _sweet_

claunia commented

@ghost commented on GitHub (Mar 1, 2021):

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

Handy links:

@ghost commented on GitHub (Mar 1, 2021): :tada:This issue was addressed in #8898, which has now been successfully released as `Windows Terminal Preview v1.7.572.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.7.572.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)

claunia commented

@santanaruben commented on GitHub (Mar 9, 2021):

If someone needs the commands to create a new tab (and not open a new window) from a context menu item are:

(if you are already in the directory):
wt -w 0 nt

(and if you click on the directory):
wt -w 0 nt -d %1

You can add these commands in the respective registry of each item (or in a new one)

@santanaruben commented on GitHub (Mar 9, 2021): If someone needs the commands to create a new tab (and not open a new window) from a context menu item are: (if you are already in the directory): `wt -w 0 nt` (and if you click on the directory): `wt -w 0 nt -d %1` You can add these commands in the respective registry of each item (or in a new one)

claunia commented

@zeroxia commented on GitHub (Mar 11, 2021):

🎉This issue was addressed in #8898, which has now been successfully released as Windows Terminal Preview v1.7.572.0.🎉

Handy links:

Release Notes

Store Download

When will this be in the stable release?

@zeroxia commented on GitHub (Mar 11, 2021): > 🎉This issue was addressed in #8898, which has now been successfully released as `Windows Terminal Preview v1.7.572.0`.🎉 > > Handy links: > > * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.7.572.0) > * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge) When will this be in the stable release?

claunia commented

@zadjii-msft commented on GitHub (Mar 11, 2021):

@zeroxia Probably in about a month.

@zadjii-msft commented on GitHub (Mar 11, 2021): @zeroxia Probably in about a month.

claunia commented

@pfmoore commented on GitHub (Mar 11, 2021):

Edit Never mind, I didn't find the right part of the documentation. wt -w 0 sp vim does exactly what I want. Thank you so much for this feature.

This is an awesome feature, and I'm really glad to see it land. But one thing from the original request that I was really looking forward to was the ability to run an arbitrary command in its own pane. Not an existing profile, but a one-off console executable.

So, for example, if I start a Jupyter Notebook server using jupyter notebook, it takes over the current console window for its logging. I can put the output in a new pane or tab by opening the pane, cd to the directory I was in in the original pane, then running jupyter notebook. But what I'd really like to be able to do would be something like wt -w 0 split-pane -d $env:CWD -exec jupyter notebook.

Did I miss a way to do this that already exists, or is this something that will be added later (or is it a part of the request that you've rejected? 🙁) Given that this issue has been closed, is there somewhere else I should be following to track progress of that part of the request?

@pfmoore commented on GitHub (Mar 11, 2021): **Edit** Never mind, I didn't find the right part of the documentation. `wt -w 0 sp vim` does *exactly* what I want. Thank you so much for this feature. ---- This is an awesome feature, and I'm really glad to see it land. But one thing from the original request that I was really looking forward to was the ability to run an *arbitrary command* in its own pane. Not an existing profile, but a one-off console executable. So, for example, if I start a Jupyter Notebook server using `jupyter notebook`, it takes over the current console window for its logging. I can put the output in a new pane or tab by opening the pane, cd to the directory I was in in the original pane, then running `jupyter notebook`. But what I'd *really* like to be able to do would be something like `wt -w 0 split-pane -d $env:CWD -exec jupyter notebook`. Did I miss a way to do this that already exists, or is this something that will be added later (or is it a part of the request that you've rejected? 🙁) Given that this issue has been closed, is there somewhere else I should be following to track progress of that part of the request?

claunia commented

@lfr commented on GitHub (Mar 12, 2021):

I can't seem to run wt commands from bash 🤔

@lfr commented on GitHub (Mar 12, 2021): I can't seem to run `wt` commands from bash 🤔

claunia commented

@mveril commented on GitHub (Mar 12, 2021):

I can't seem to run wt commands from bash 🤔

To run Windows executable from WSL you need to add the .exe extension explicitly. So wt.exe should work

@mveril commented on GitHub (Mar 12, 2021): > I can't seem to run `wt` commands from bash 🤔 To run Windows executable from WSL you need to add the .exe extension explicitly. So `wt.exe` should work

claunia commented

@fredrikhr commented on GitHub (Mar 12, 2021):

@mveril @lfr

To run Windows executable from WSL you need to add the .exe extension explicitly. So wt.exe should work

That depends. If you have installed Terminal through the Windows Store running wt.exe does not work. And yes, that's even though which wt.exe retuns a valid path to the C: mount point

$ wt.exe
# noting happens, but also no error
$ which wt.exe
/mnt/c/Users/<UserName>/AppData/Local/Microsoft/WindowsApps/wt.exe

Naturally, running cmd.exe /c wt does work, but that was kinda expected and is a really ugly hack...

@fredrikhr commented on GitHub (Mar 12, 2021): @mveril @lfr > To run Windows executable from WSL you need to add the `.exe` extension explicitly. So `wt.exe` should work That depends. If you have installed Terminal through the Windows Store running `wt.exe` does not work. And yes, that's even though `which wt.exe` retuns a valid path to the `C:` mount point ``` $ wt.exe # noting happens, but also no error $ which wt.exe /mnt/c/Users/<UserName>/AppData/Local/Microsoft/WindowsApps/wt.exe ``` Naturally, running `cmd.exe /c wt` **does** work, but that was kinda expected and is a really ugly hack...

claunia commented

@lfr commented on GitHub (Mar 12, 2021):

Thanks @fredrikhr, isn't the store the "official" way to install Windows Terminal? What's the other way to install it that wouldn't cause this issue?

@lfr commented on GitHub (Mar 12, 2021): Thanks @fredrikhr, isn't the store the "official" way to install Windows Terminal? What's the other way to install it that wouldn't cause this issue?

claunia commented

@ngmariusz commented on GitHub (Mar 12, 2021):

I'm alittle confused that it's closed issue; i've discoverd this one after submitting the feedback in https://github.com/microsoft/terminal/issues/9368; I think it's related and perhaps this should be still open?

@ngmariusz commented on GitHub (Mar 12, 2021): I'm alittle confused that it's closed issue; i've discoverd this one after submitting the feedback in https://github.com/microsoft/terminal/issues/9368; I think it's related and perhaps this should be still open?

claunia commented

@mreymann commented on GitHub (Mar 12, 2021):

I didn't even know calling Windows binaries works at all! ;-) cmd.exe works, wt.exe doesn't:

[12:14:33][pigpen@box:~]$ which wt.exe
/mnt/c/Users/<USER>/AppData/Local/Microsoft/WindowsApps/wt.exe

[12:15:03][pigpen@box:~]$ strace wt.exe
execve("/mnt/c/Users/<USER>/AppData/Local/Microsoft/WindowsApps/wt.exe", ["wt.exe"], 0x7ffff5c7a1b0 /* 24 vars */) = -1 ENOEXEC (Exec format error)
strace: exec: Exec format error
+++ exited with 1 +++

@mreymann commented on GitHub (Mar 12, 2021): I didn't even know calling Windows binaries works at all! ;-) cmd.exe works, wt.exe doesn't: ``` [12:14:33][pigpen@box:~]$ which wt.exe /mnt/c/Users/<USER>/AppData/Local/Microsoft/WindowsApps/wt.exe [12:15:03][pigpen@box:~]$ strace wt.exe execve("/mnt/c/Users/<USER>/AppData/Local/Microsoft/WindowsApps/wt.exe", ["wt.exe"], 0x7ffff5c7a1b0 /* 24 vars */) = -1 ENOEXEC (Exec format error) strace: exec: Exec format error +++ exited with 1 +++ ```

claunia commented

@fredrikhr commented on GitHub (Mar 12, 2021):

@mreymann Yeah, this is caused by this AppContainer isolation layer of Appx Packages (Microsoft Store apps) and how their executables are placed in the %LOCALAPPDATA%\Microsoft\WindowsApps folder. The files in there both are and are not there or at least are not really executable, but the Windows OS does some weird magic trick to actually start the correct binary from wherever the App is actully installed. Which is why starting the exe from a windows-shell starting point works, whereas from a WSL2-starting point it does not.

Would be interesting whether the technology used in WSL1 leads to this actually working, or not...

@fredrikhr commented on GitHub (Mar 12, 2021): @mreymann Yeah, this is caused by this AppContainer isolation layer of Appx Packages (Microsoft Store apps) and how their executables are placed in the `%LOCALAPPDATA%\Microsoft\WindowsApps` folder. The files in there both are and are not there or at least are not really executable, but the Windows OS does some weird magic trick to actually start the correct binary from wherever the App is actully installed. Which is why starting the exe from a windows-shell starting point works, whereas from a WSL2-starting point it does not. Would be interesting whether the technology used in WSL1 leads to this actually working, or not...

claunia commented

@JenuelDev commented on GitHub (Apr 21, 2021):

If someone needs the commands to create a new tab (and not open a new window) from a context menu item are:

(if you are already in the directory):
wt -w 0 nt

(and if you click on the directory):
wt -w 0 nt -d %1

You can add these commands in the respective registry of each item (or in a new one)

this really works it open a new tab, the problem is the directory was reset,.. hoping that I open a new tab, it will be at the same directory in my working project.

@JenuelDev commented on GitHub (Apr 21, 2021): > If someone needs the commands to create a new tab (and not open a new window) from a context menu item are: > > (if you are already in the directory): > `wt -w 0 nt` > > (and if you click on the directory): > `wt -w 0 nt -d %1` > > You can add these commands in the respective registry of each item (or in a new one) this really works it open a new tab, the problem is the directory was reset,.. hoping that I open a new tab, it will be at the same directory in my working project.

claunia commented

@santanaruben commented on GitHub (Apr 21, 2021):

@BroJenuel

The first case was a modification.
The second one I had to create.

@santanaruben commented on GitHub (Apr 21, 2021): @BroJenuel ![0](https://user-images.githubusercontent.com/39445525/115571407-f71e2080-a28c-11eb-879e-44bcb82cbd74.jpg) ![1](https://user-images.githubusercontent.com/39445525/115571497-0dc47780-a28d-11eb-9ff6-329b4f17fc1b.jpg) The first case was a modification. The second one I had to create.

claunia commented

@androiddevnotes commented on GitHub (Aug 27, 2021):

If someone needs the commands to create a new tab (and not open a new window) from a context menu item are:
(if you are already in the directory):
wt -w 0 nt
(and if you click on the directory):
wt -w 0 nt -d %1
You can add these commands in the respective registry of each item (or in a new one)

this really works it open a new tab, the problem is the directory was reset,.. hoping that I open a new tab, it will be at the same directory in my working project.

Try this:

wt -w 0 nt -d .

@androiddevnotes commented on GitHub (Aug 27, 2021): > > If someone needs the commands to create a new tab (and not open a new window) from a context menu item are: > > (if you are already in the directory): > > `wt -w 0 nt` > > (and if you click on the directory): > > `wt -w 0 nt -d %1` > > You can add these commands in the respective registry of each item (or in a new one) > > this really works it open a new tab, the problem is the directory was reset,.. hoping that I open a new tab, it will be at the same directory in my working project. Try this: ``` wt -w 0 nt -d . ```

claunia commented

@lfr commented on GitHub (Aug 30, 2021):

And what would the commands be to open a new tab from within the terminal itself?

@lfr commented on GitHub (Aug 30, 2021): And what would the commands be to open a new tab from within the terminal itself?

claunia commented

@zadjii-msft commented on GitHub (Aug 30, 2021):

wt -w 0 nt

@zadjii-msft commented on GitHub (Aug 30, 2021): ``` wt -w 0 nt ``` ![wt-w-0](https://user-images.githubusercontent.com/18356694/131349062-56297187-92fd-43c8-9a3a-ed745d878b49.gif)

claunia commented

@lfr commented on GitHub (Aug 30, 2021):

@zadjii-msft thanks, but it doesn't seem to work from bash (Terminal Preview) 🤷‍♂️

@lfr commented on GitHub (Aug 30, 2021): @zadjii-msft thanks, but it doesn't seem to work from bash (Terminal Preview) 🤷‍♂️

claunia commented

@zadjii-msft commented on GitHub (Aug 30, 2021):

Ah, from WSL you'll need:

cmd.exe /c "wt.exe" -w 0 nt

Execution aliases do not work in WSL distributions. If you want to use wt.exe from a WSL command line, you can spawn it from CMD directly by running cmd.exe. The /c option tells CMD to terminate after running.

Also, you can read this in the docs

@zadjii-msft commented on GitHub (Aug 30, 2021): Ah, from WSL you'll need: ``` cmd.exe /c "wt.exe" -w 0 nt ``` Execution aliases do not work in WSL distributions. If you want to use `wt.exe` from a WSL command line, you can spawn it from CMD directly by running `cmd.exe`. The `/c` option tells CMD to terminate after running. Also, you can read this in [the docs](https://docs.microsoft.com/en-us/windows/terminal/command-line-arguments?tabs=linux)

claunia commented

@hardeepparmar commented on GitHub (Aug 30, 2021):

wt -w 0 nt

But this works only from with in cmd tab window.. This does not work if you issue this command from say within powershell tabbed window.

@hardeepparmar commented on GitHub (Aug 30, 2021): > ``` > wt -w 0 nt > ``` > > ![wt-w-0](https://user-images.githubusercontent.com/18356694/131349062-56297187-92fd-43c8-9a3a-ed745d878b49.gif) But this works only from with in cmd tab window.. This does **not** work if you issue this command from say within powershell tabbed window.

claunia commented

2026-01-31 00:35:00 +00:00

@zadjii-msft commented on GitHub (Aug 30, 2021):

But this works only from with in cmd tab window.. This does not work if you issue this command from say within powershell tabbed window.

🤔

@zadjii-msft commented on GitHub (Aug 30, 2021): > But this works only from with in cmd tab window.. This does **not** work if you issue this command from say within powershell tabbed window. ![wt-w-0--powershell](https://user-images.githubusercontent.com/18356694/131371736-61579536-49b5-4b70-99b0-19bc7dbbfb28.gif) 🤔

claunia commented

@DJackman123 commented on GitHub (Aug 30, 2021):

Beat me to the punch. Yes, it does work in a PowerShell tab. However, it does not work in a Windows Terminal window running as administrator (see #9628).

@DJackman123 commented on GitHub (Aug 30, 2021): Beat me to the punch. Yes, it _does_ work in a PowerShell tab. However, it _does not_ work in a Windows Terminal window running as administrator (see #9628).

claunia commented

2026-01-31 00:35:00 +00:00

@hardeepparmar commented on GitHub (Sep 2, 2021):

Beat me to the punch. Yes, it does work in a PowerShell tab. However, it does not work in a Windows Terminal window running as administrator (see #9628).

Yes indeed i am running Windows terminal as Administrator and I see this issue...However as you said, if I do not run at as administrator, it works just as expected. Thanks for confirming and making it more explicit and clear.

@hardeepparmar commented on GitHub (Sep 2, 2021): > Beat me to the punch. Yes, it _does_ work in a PowerShell tab. However, it _does not_ work in a Windows Terminal window running as administrator (see #9628). Yes indeed i am running Windows terminal as Administrator and I see this issue...However as you said, if I do not run at as administrator, it works just as expected. Thanks for confirming and making it more explicit and clear.

claunia commented

2026-01-31 00:35:01 +00:00

@MetaMmodern commented on GitHub (Feb 12, 2022):

For those who are kinda new to this: here is how you can do it the easy way.(Works for me in Windows 10 Pro with Windows Terminal(not Preview))

Open Windows Terminal.
Open Settings.
Checkout this section in the startup menu.
Select as I did.
Test by clicking "Open in Windows Terminal" elsewhere.
Thanks Microsoft for adding this to GUI)

@MetaMmodern commented on GitHub (Feb 12, 2022): For those who are kinda new to this: here is how you can do it the easy way.(Works for me in Windows 10 Pro with Windows Terminal(not Preview)) 1. Open Windows Terminal. 2. Open Settings. 3. Checkout this section in the startup menu. ![image](https://user-images.githubusercontent.com/42899786/153727389-56f004b6-cd7b-4b35-9531-ef2227e28638.png) 4. Select as I did. 5. Test by clicking "Open in Windows Terminal" elsewhere. Thanks Microsoft for adding this to GUI)

claunia commented

2026-01-31 00:35:01 +00:00

@LawranceFung commented on GitHub (Feb 13, 2022):

For those who are kinda new to this: here is how you can do it the easy way.

1. Open Windows Terminal.

2. Open Settings.

3. Checkout this section in the startup menu.
   ![image](https://user-images.githubusercontent.com/42899786/153727389-56f004b6-cd7b-4b35-9531-ef2227e28638.png)

4. Select as I did.

5. Test by clicking "Open in Windows Terminal" elsewhere.
   Thanks Microsoft for adding this to GUI)

Neither "Attach to the most recently used window" nor "Attach to the most recently used window on this desktop" work for me on Windows 11. I am not using the Preview version of Windows Terminal. Any idea what's up?

@LawranceFung commented on GitHub (Feb 13, 2022): > For those who are kinda new to this: here is how you can do it the easy way. > > 1. Open Windows Terminal. > > 2. Open Settings. > > 3. Checkout this section in the startup menu. > ![image](https://user-images.githubusercontent.com/42899786/153727389-56f004b6-cd7b-4b35-9531-ef2227e28638.png) > > 4. Select as I did. > > 5. Test by clicking "Open in Windows Terminal" elsewhere. > Thanks Microsoft for adding this to GUI) Neither "Attach to the most recently used window" nor "Attach to the most recently used window on this desktop" work for me on Windows 11. I am not using the Preview version of Windows Terminal. Any idea what's up?

claunia commented

2026-01-31 00:35:01 +00:00

@MetaMmodern commented on GitHub (Feb 13, 2022):

For those who are kinda new to this: here is how you can do it the easy way.
1. Open Windows Terminal.

2. Open Settings.

3. Checkout this section in the startup menu.
   ![image](https://user-images.githubusercontent.com/42899786/153727389-56f004b6-cd7b-4b35-9531-ef2227e28638.png)

4. Select as I did.

5. Test by clicking "Open in Windows Terminal" elsewhere.
   Thanks Microsoft for adding this to GUI)
Neither "Attach to the most recently used window" nor "Attach to the most recently used window on this desktop" work for me on Windows 11. I am not using the Preview version of Windows Terminal. Any idea what's up?

Sorry, buddy, no idea. Try checking the above comments (like modifying the registry). I'll update my prev comment, cuz I'm on windows 10.

@MetaMmodern commented on GitHub (Feb 13, 2022): > > For those who are kinda new to this: here is how you can do it the easy way. > > > > 1. Open Windows Terminal. > > > > 2. Open Settings. > > > > 3. Checkout this section in the startup menu. > > ![image](https://user-images.githubusercontent.com/42899786/153727389-56f004b6-cd7b-4b35-9531-ef2227e28638.png) > > > > 4. Select as I did. > > > > 5. Test by clicking "Open in Windows Terminal" elsewhere. > > Thanks Microsoft for adding this to GUI) > > Neither "Attach to the most recently used window" nor "Attach to the most recently used window on this desktop" work for me on Windows 11. I am not using the Preview version of Windows Terminal. Any idea what's up? Sorry, buddy, no idea. Try checking the above comments (like modifying the registry). I'll update my prev comment, cuz I'm on windows 10.

claunia commented

@LawranceFung commented on GitHub (Feb 13, 2022):

Are there plans to launch a new tab in an existing window, but to choose the window based on MRU order?

@LawranceFung commented on GitHub (Feb 13, 2022): Are there plans to launch a new tab in an existing window, but to choose the window based on MRU order?

claunia commented

@zadjii-msft commented on GitHub (Feb 14, 2022):

choose the window based on MRU order?

that's... already how it's supposed to work?

@zadjii-msft commented on GitHub (Feb 14, 2022): > choose the window based on MRU order? that's... already how it's supposed to work? ![mru-wt--w-0](https://user-images.githubusercontent.com/18356694/153857722-b710895f-ccb5-435a-8568-1e89729400b6.gif)

claunia commented

@DJackman123 commented on GitHub (Feb 14, 2022):

Are there plans to fix issue #9628 so I can actually use this feature?

@DJackman123 commented on GitHub (Feb 14, 2022): Are there plans to fix issue #9628 so I can actually use this feature?

claunia commented