Support configuring the local terminal launched in remote windows

[Jademalo]

My workflow requires compilation in Linux, but running the produced artefact in Windows. This requires me constantly jumping between a whole variety of terminals, and is very inconvenient.
Currently there are numerous bits of disparate support for host shells and terminals when using remotes, but none of the solutions seem to actually work properly. This is especially evident when it comes to tasks.

My current approach involves using the WSL remote, with the following configuration.
Local terminals seem to have been added to the terminal dropdown with the WSL extension, due to the following being automatically added to my user settings;

"terminal.integrated.profiles.linux": {
    "PowerShell (WSL Host)": {
        "path": "/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe",
        "icon": "terminal-powershell"
    },
    "Command Prompt (WSL Host)": {
        "path": "/mnt/c/Windows/System32/cmd.exe",
        "icon":"terminal-cmd"
      }
}

Since WSL automatically mounts all windows drives, these paths seem to work correctly. These terminals seem to be running from the host, so any commands run are executed as the host PC rather than the WSL instance. This is useful, and allows running commands from both the WSL instance and the host. However, this seems to be a workaround exclusive to WSL due to it's automatic mounting of the windows drives and doesn't work for container remotes.

When opening the command palette, there are two interesting commands - Terminal: Create New Terminal (In Active Workspace) and Terminal: Create New Terminal (Local).
The first seems to open a new terminal in the same manner as Ctrl+Shift+', however the second is extremely weird and I can't find much documentation on it. It seems to open a local powershell on windows, but there's no configuration for it.

It's not possible to add this terminal to terminal.integrated.profiles.linux to add it to the terminal choice dropdown, since it seems to be entirely separate to the rest of the terminal functionality and settings.
It's also not possible to use this shell in any sort of tasks, since again it doesn't exist as a terminal profile and seems to be it's own separate thing.

Ultimately, there seems to be extremely inconsistent and unintuitive support for using the host shell, and it varies by the type of remote you're using. In addition, there seems to be little documentation on this, so what is actually possible is extremely vague.
To try and make this a bit more consistent, I suggest the following;

• Expose the shell created by Terminal: Create New Terminal (Local) as a source to add to terminal.integrated.profiles.*, allowing it to be added to the shell dropdown and selected as the default.
• Add the ability to configure the local shell that is opened with Terminal: Create New Terminal (Local).

This should ultimately allow something like;

settings.json

"terminal.integrated.profiles.linux": {
    "bash":{
        "path": "/bin/bash",
        "icon": "terminal-bash"
    },
    "PowerShell (Local)": {
        "source": "local",
        "icon": "terminal-powershell"
    }
},
"terminal.integrated.defaultProfile.linux": "bash",

"terminal.intergrated.profiles.local": {
    "PowerShell":{
        "path": [
            "${env:windir}\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
        ],
        "icon": "terminal-powershell"
    }
}
"terminal.integrated.defaultProfile.local": "PowerShell",

This would make using local shells as easy as using remote shells. This would greatly improve the usability of Container remotes, and get rid of the hacky workarounds that are necessary for WSL remotes.

[Tyriar]

I feel like the essence of this issue is to allow the Terminal: Create New Terminal (Local) command to be configurable. For more specific requests on the automation profile could you create another issue?

For some historical context, originally it wasn't possible to create local terminals in remotes at all (excluding your workaround), this was a quick command added to allow the bare minimum of a "default" local terminal to get launched.

I ultimately do not understand why terminal.integrated.automationProfile.* even exists

The reason was because many of the keys in a profile like the args/env/etc. would not apply to task terminals. It replaced the older terminal.integrated.automationShell.<platform> settings which only allowed specifying a path. I think "local task" support is the ask here which I haven't thought about too much.

[Jademalo]

Alright, that all seems reasonable.
I'll split off the stuff associated with automation into a separate ticket, with how intertwined all of the systems are I wasn't exactly sure what was right to split.
I'll also create a bug for the WSL local terminal issue, since that definitely seems strange.

[Jademalo]

Ok, this has now been split into 3 tickets - This ticket for local terminal configuration, #146047 covering using local shells when running tasks, and #146040 for the bug with WSL and the local terminal.

[juanrgm]

Same case here.

I need open a window terminal with GitBash/WSL profile from a linux container. The terminal is always opened with Powershell profile and I can't change it.

Why GitBash/WSL? Becase when a path appears in the local terminal, if I try click it (Open file in editor) the path separator will be converted to win32 style.

[melink14]

I wanted my local terminal to be WSL when opening from Codespaces as well. I thought setting terminal.integrated.profiles.windows with a wsl path and making it the defaultProfile would work but it seems to be ignored.

[red8888]

@Tyriar want to confirm my issue is the same as this issue because I don't use WSL just dev containers.

When I'm in a dev container and try to Terminal: Create New Terminal (Local) to get an integrated terminal on the host (not in the dev container) I get an error: The terminal process failed to launch: Path to shell executable "/usr/bin/zsh" does not exist. My shell is at /opt/homebrew/bin/zsh.

I tried all the shell settings, but they are ignored- this is the same issue as this ticket right?

Currently these are my only shell settings and when I open a non dev container project I get my default shell from /opt/homebrew/bin/zsh correctly.

    "terminal.external.osxExec": "iTerm.app",
    "terminal.external.linuxExec": "iterm",
    "terminal.integrated.fontFamily": "MesloLGS NF",
    "terminal.integrated.inheritEnv": false,

On Macos its even worse because I can't even throw a symlink in /usr/bin/.

Is there currently no way to fix this and change the path of Terminal: Create New Terminal (Local)?

[zeeshansayyed]

@Tyriar @red8888 I have the same issue. When I try to do Terminal: Create New Terminal (Local), I get an error saying The terminal process failed to launch: Path to shell executable "/usr/bin/bash" does not exist.. I have tried many things but haven't been able to configure how to set this path so that VSCode finds this.

My setup: I am running a docker container on a MacBook. When I do not open the project in a container, creating a terminal correctly connects to my local MacBook shell. When I open the project in a container, it connects to a shell within the docker container. But I want to open a terminal which connects to my MacBook shell even when I open a project in a container using dev containers.