Change:
// Await the initialization of available profiles as long as this is not a pty terminal or a // local terminal in a remote workspace as profile won't be used in those cases and these // terminals need to be launched before remote connections are established. <del> if (!this._terminalProfileService.availableProfiles) { const isPtyTerminal = options?.config && 'customPtyImplementation' in options.config; const isLocalInRemoteTerminal = this._remoteAgentService.getConnection() && URI.isUri(options?.cwd) && options?.cwd.scheme === Schemas.vscodeFileResource; if (!isPtyTerminal && !isLocalInRemoteTerminal) { await this._terminalProfileService.refreshAvailableProfiles(); } </del> <ins> const isPtyTerminal = options?.config && 'customPtyImplementation' in options.config; const isLocalInRemoteTerminal = this._remoteAgentService.getConnection() && URI.isUri(options?.cwd) && options?.cwd.scheme === Schemas.vscodeFileResource; if (!isPtyTerminal && !isLocalInRemoteTerminal) { await this._terminalProfileService.profilesReady; </ins> } const config = options?.config || this._terminalProfileService.availableProfiles?.find(p => p.profileName === this._terminalProfileService.getDefaultProfileName());

Discussion:
<!-- Please search existing issues to avoid creating duplicates, and review our troubleshooting tips: --<!-- Please attach logs to help us diagnose your issue. Learn more here: --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --- VSCode Version: 1.63.0 Local OS Version: Windows 10 20H2 Remote OS Version: N/A Remote Extension/Connection Type: SSH/Docker/WSL Logs: Unable to find source log that indicates terminal launch Steps to Reproduce: VSCode CTRL+~ to open terminal Killing the terminal and executing step 2 will open the default terminal (Git Bash for me) <!-- Check to see if the problem is general, with a specific extension, or only happens when remote --Does this issue occur when you try this locally?: Yes Does this issue occur when you try this locally and all extensions are disabled?: Yes <!-- If your issue only appears in Codespaces, please visit: --!
This was meant to be fixed, maybe not?
also see the icon, indicates that the default profile is likely undefined so we use the fallback
Maybe not related to remote? I see this in your report: What type of window were you in where you saw this? You can take a screenshot of the bottom left corner of the window to tell us this.
Yeah that was in error. It was not any of those
I have the same issue. And I'am working remote with SSH. This issue was fixed, but it came back with the last update.
It also gives me powershell when I typed code inside wsl and open the vs code. Any solution for that?
Mea culpa, just rebooted and the issue persists
This 'was' fixed. For several months.. It seems the bug is back. ! You can see from the screenshot, it even states "Git Bash" as default, but you can see it has opened a powershell on VSCode Startup. ! Version: 1.63.2 (system setup) Commit: Date: 2021-12-15T09:40:02.816Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0.

Additional Info: vs Hope these steps help. PS: I have the feature turned on that opens up the last used Project when opening a VSCode while no other vscode instances are open. I also do not have the 'welcome' window.. Not sure if it makes a difference, as I can't find out to turn it on/off again to test. But thought best to say incase it changes things.
I have the same issue, too. But there is one difference to : After a reboot, it opens Powershell every time. When opening VS Code several times during a windows session, some of the times the correctly configured git bash is opened. So maybe this could be related to caching oder something like that.
My default is Git Bash but I get Powershell on every first launch after a Windows reboot.
This ticket appears to be Windows-specific, but there are also issues with the incorrect terminal type being opened after a window reloads on other platforms. Tasks related to those are getting marked as duplicates of this. Does this task cover Linux and OS X issues as well?
Being really quick at the start of VSCode (or having a rather slow PC), I managed to see something interesting. At the very first moment, there is only Powershell in the terminal window at the add shell menu. So it seems that VSCode is loaded with a default menu (and therefore a default startup shell), and that is being run before the configuration is being read. This also makes sense with the fact that after a second start, the correct shell is being loaded: the configuration files simply seem to be still cached, making it quick enough for VSCode to overwrite the default start with the current configuration.
Hello there! I found a bug in the line 921 of the file It never enters in the next condition when the terminal profiles are not loaded already because !Array() is always false. I hope it can be helpful. See you soon.
It has something to do with the -nologo arg and automatic updates for me. Even though my default terminal is set to bash as well, whenever there is a new version of Powershell VSCode starts with a Powershell terminal until I upgrade to the latest version -close all terminals in VSCode -shut VSCode down and restart. It will work fine until the next update.

Users of Windows Terminal have the option of using the -nologo arg to suppress this, not sure if there is some workaround for VSCode users.
What would you expect the behavior to be with terminal reattach? had closed my SSH remote window after testing something else. set my default Windows profile to be "Git Bash". reconnected to it to verify this issue. got reconnected to my PowerShell terminal.
Actually, I see this repro even when not reattaching.
I was seeing it pretty consistently when my default shell was pwsh on Code - OSS/macOS
not able to reproduce this in insider's on macOS
interesting - can reproduce in OSS though on macOS
removing this throttle fixes it
that's a little strange as your fix above is awaiting . Does that mean the first available profiles aren't correct but the second one 2 seconds later is?
yes when has been awaited, the length of the available profiles is still 0
is this 5 seconds too little? Does changing that to a large number like also fix the problem?
yes
Great! The problem must be the shared process + pty host takes too long to startup sometimes. So if it's more than 5 seconds we create it using the fallback shell launch config and then still wait for the start up anyway. How about we change it to 20 seconds and then change the barrier open to: