Change:
private _profilesReadyBarrier: AutoOpenBarrier | undefined; private _profilesReadyPromise: Promise<void>; private _availableProfiles: ITerminalProfile[] | undefined; <ins> private _automationProfile: unknown; </ins> private _contributedProfiles: IExtensionTerminalProfile[] = []; private _defaultProfileName?: string; private _platformConfigJustRefreshed = false;

Discussion:
<!-- 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. --- VS Code Version: 1.78.1 (user setup) OS Version: Windows 11 Steps to Reproduce: setting as shown below no terminal open, start a debugging session newly spawned debugging terminal does not respect the setting. I want to pass command line arguments to the shell the debugger terminal is about to use (PowerShell). The documentation, , states I can use the key, to do this. This simply does not seem to work at all, I have tried several different set ups (fresh code, different machines etc), nothing works. All extensions are disabled accept for The PowerShell-ms extension (version ), in order to demonstrate this issue. If in my user settings I only have the following: and a single config in my file: With no terminals open, starting a debugging session with the active file, spawns a new terminal but it is run as if the setting is not in place:  In fact, entirely different command line arguments are being passed to the PowerShell executable, as shown here:  I have run into this issue with the Python-ms Debugger and PowerShell-ms Debugger. With the standard Code terminal I can pass command line arguments to its PowerShell executable like this, and it works as shown :
does debugging respect the automation shell? I'm pretty sure it did in the past if not. This is where tasks uses it for example:
I think something is wrong, we ask for the automation profile here and I set but that profile isn't returned, I get the default zsh profile. Am I missing something?

do you have a simple that I could test this against that doesn't use the pwsh extension? I see tasks is working fine: !
I just used something like this
The automation profile on the ext host doesn't have the args in it: !
Looks like we just don't react to changes when automation profile changes, updating the default profile after setting the automation profile will trigger the update and then work properly.
Hello, looks like this issue got completed. I am not very familiar with Github. Is it safe to assume that the fix will be present in the next VSCode update? Also thank you both for working on this, I really appreciate it.
we're just about to release 1.83 and it won't be in that one unfortunately, it'll be shipped in a month to VS Code, or in a few days to .
Okay, got it!