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

[Danthar]

Description of the new feature/enhancement

I have been playing around with Jetbrains Rider, and when i start a console app with that IDE, it runs the console window inside a docked window in the IDE.

So what i was thinking. How cool would it be, if Windows Terminal allows external applications to start a new Console window in the currently running Windows Terminal instance.

That way whether its VisualStudio or Rider, those IDE's can be configured to start a new Console window inside the Windows Terminal instance.

The way i see this working is: I press F5/ctrl-F5 in visual studio, and instead of opening a new cmd console window, a new tab appears in my running Windows Terminal instance.

[lostmsu]

Yes, please. There's a Visual Studio extension, that lets you open command line in the current project folder. I set it to launch wt.exe, and it always creates a new window, but I'd love if I could pass a parameter to wt.exe, so that if Terminal is already running, it would be activated a new tab would open there instead.

[DHowett-MSFT]

Thanks for the request! I thought we had a backlog item for "allow remote control of a terminal" (like: wt.exe could --remote to control another open instance and add tabs or whatever), but it looks like we don't.

This is now that issue. Triaged into backlog.

/cc @zadjii-msft: I may be wrong in not finding a "remote control" issue

[DHowett-MSFT]

Partially supported by #2080.

[zadjii-msft]

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.

[Rumbah2]

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).

[nmyron]

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

[zadjii-msft]

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.

[nmyron]

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?

[zadjii-msft]

@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 ☺️

[nmyron]

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" }

[zadjii-msft]

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

[FallenGameR]

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?

[zadjii-msft]

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

[lfr]

@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.

[FallenGameR]

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.

[hd321kbps]

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.

[mreymann]

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?

[zadjii-msft]

@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.

[bmaehr]

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.

[FireEmerald]

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 🙄

[xcme]

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.

[GoodClover]

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

[zadjii-msft]

@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]

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).