Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.58.0-insider (user setup) Commit: Date: 2021-07-01T09:30:57.217Z Electron: 12.0.13 Chrome: 89.0.4389.128 14.16.0 V8: 8.9.255.25-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: error I think only occurs using Workspaces. A single project, the terminals seem to work fine. However, with multiple projects, the environment gets confused. Terminal (ctrl+shift+) Terminal I get this error message: 'The termial process failed to launch: Starting directory (cwd) "homeusernamemyproject"'. The first terminal works, but it's the second or subsequent terminal that creates the error. This is using the VSCode for Windows using WSL Remote. This error has now existed for at least a week in the Insiders edition. I am surprised this has not already been brought up. I think the error is indicating that its confusing a windows path for a linux path. Because this is using WSL-Remote, the path should be using forward slashes not backslashes for windows. This happens when "terminal.integrated.splitCwd" is inherited or initial. The workaround is to set this to workspaceRoot, then it works. However, it's annoying not to have inherited or initial working. Also, nowhere in my settings is "cwd" assigned anywhere. Also there is , but I suspect the issue on MacOS is different. Jae
The bottom line: Only while using Workspaces, the first or default terminal is properly run in WSL2. However, any subsequent new terminals are being recognized as a Windows environment, not Linux. Somehow the combination of Workspace+WSL is messing up the terminal environment.
I just discovered there is a command called "Create new Integrated terminal (In Active Workspace)"; where as the default "New Terminal" calls "Create new Integrated terminal". This is another possible workaround. However, you have to make sure the active file is where you want the new terminal to be created. You lose the ability to select which folder to create the new terminal in, unfortunately.
Can repro: ! multi-root workspace in WSL +shift+ +shift+5
Ah this is happening because we're getting a instead of a here:
I'm also getting this issue when using inherited for workspaces and remote ssh from a windows to a linux host. If I reload the window I am able to split the terminal for terminals that were created before the reload. Version: 1.58.2 (system setup) Commit: Date: 2021-07-14T22:10:15.214Z Electron: 12.0.13 Chrome: 89.0.4389.128 14.16.0 V8: 8.9.255.25-electron.0 OS: Windows_NT x64 10.0.
Same here.
As a workaround for this issue in version 1.58, I was using this setting: But now in version 1.59.0, the issue happens with any values .
Awesome! Just got the fix in insiders! Thank you!
Verified fixed in

Discussion:
if (options?.instanceToSplit && typeof shellLaunchConfig.cwd !== 'object' && typeof options.instanceToSplit.shellLaunchConfig.cwd === 'object') { shellLaunchConfig.cwd = URI.from({ scheme: options.instanceToSplit.shellLaunchConfig.cwd.scheme, <ins> authority: options.instanceToSplit.shellLaunchConfig.cwd.authority, </ins> path: shellLaunchConfig.cwd || options.instanceToSplit.shellLaunchConfig.cwd.path }); }