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?: No (have to use extension from microsoft to get the launch type, but with all others disabled I still see this issue) <!-- 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. --- VS Code Version: 1.86.0 OS Version: WindowsNT x64 10.0. Steps to Reproduce: default setting for of up a configuration which uses of using that launch configuration that a new Windows Terminal window is opened, with a popup stating: The following argument was not expected: /c Run with --help for more information_ I would have expected this if I set my to ; but it's still set to - not sure why this is happening (it didn't happen yesterday, and I haven't modified any settings) Any help would be appreciated, if there's a particular log I can look in I'd gladly do so. Thank you!
I have the same issue since upgrading from 1.85 to 1.86. From my little investigation I suspect that this is due to the changes from I see that the application being spawned begins with: It looks like the Current Directory parameter (following -d) is not set, probably an empty string from what I can see see looking at the code :
I pretty agree with the response above that some troubles are in external terminal service function .
Update, if it's helpful, the launch that we're using is of type:
This comment is correct. Based on the DAP for RunInTerminalRequest, even if was null, it would use as the directory before. That commit breaks the scenario where a debug adapter sends an empty string for 'cwd'. See
any update on this? like is it confirmed and a fix will come, or do i have to stay on 1.85.2 forever now?
Please fix - downgraded to 1.85 to deal with it; auto-update just brought 1.86 back and it's broken again... This is a major usability issue
Thanks for the investigation, Sebastian. I applied a fix to ensure a directory is passed when launching Please let me know if that resolves the issue. is still respected as the shell we launch use in the windows terminal, but since the last release we prefer to run that in the Windows Terminal since there were issues that came up if we launch directly.
So I'm getting this ! with the following config: and additionally the default value or manually setting: both open WT, though they do have cmd running inside. Which it sounds like is the expected behavior.
Closing this issue now that the candidate PR has been merged.
<!-- UNABLETOLOCATECOMMITMESSAGE issue --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased
I'm still seeing Tyler's issue with the latest Insiders. Let me know if there are any logs I can attach.
I am still seeing this issue. It is likely a problem with core VS Code, not the cpptools extension. See my comment here: TL;DR: Set to be (or ) to work around the issue.

Discussion:
// prefer to use the window terminal to spawn if it's available instead // of start, since that allows ctrl+c handling (#81322) spawnExec = wt; <del> cmdArgs = ['-d', dir, exec, '/c', command]; </del> <ins> cmdArgs = ['-d', dir || '.', exec, '/c', command]; // default dir fixes #204039 </ins> } else { spawnExec = WindowsExternalTerminalService.CMD; cmdArgs = ['/c', 'start', title, '/wait', exec, '/c', command];