VSCode overrides PowerShell ExecutionPolicy

When using Get-ExecutionPolicy -list within VSCode for PowerShell v5 x64 & x86 it returns the following:

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process          Bypass
  CurrentUser       Undefined
 LocalMachine       Undefined

When using the same command within VSCode and using a PowerShell v7 console it returns:

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process    RemoteSigned
  CurrentUser       Undefined
 LocalMachine    RemoteSigned

There are 2 registry entries that set the ExecutionPolicy (Originally: ByPass)

HKEY_CLASSES_ROOT\Microsoft.PowerShellScript.1\Shell\0\Command      REG_SZ  "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-Command" "if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process RemoteSigned }; & '%1'" 
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Microsoft.PowerShellScript.1\Shell\0\Command        REG_SZ  "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-Command" "if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process RemoteSigned }; & '%1'"

These 2 entries were originally set to Set the Execution Policy to ByPass , and I have set these 2 entries manually to RemoteSigned. (why are these 2 entries within the registry and why were they set to bypass?!).

There are no further Policies set for PowerShell within the registry then these 2 entries. Setting these to RemoteSigned seemed to have done the trick for v7 but not for v5.

When checking the ExecutionPolicy within a v5 PowerShell Console they are all undefined.

when checking the vscode-powershell.log it says that it starts PowerShell with arguments:
PowerShell args: -NoProfile -NonInteractive -ExecutionPolicy Bypass -Command Import-Module ...

I can see the vscode powershell extension sets some of these parameters within the following file: C:\Users\UserName.vscode\extensions\ms-vscode.powershell-2020.3.0\out\src\process.js
But I am not sure if this is the correct file to make these changes.

I want to be able to check/set the ExecutionPolicy for VSCode to RemoteSigned when it starts the language server , where do I do this?

Also , Why are there 2 entries within the registry that sets the ExecutionPolicy to ByPass when the ExecutionPolicy Not Equals AllSigned. This might have occurred after having installed Chocolatey using their one line installer: Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

Im not using any profiles.

I know its a bit messy, sorry for that , my main question is where VSCode sets the ExecutionPolicy when starting the language server and can I change this. When doing some investigation, I figured there was 2 registry entries that sets the ExecutionPolicy to bypass , why is that , is that standard , looks like a security issue. (which might have caused by installing chocolatey, not sure)

Solution

The PowerShell extension for Visual Code respects the persistent execution policy settings^[1] of whatever PowerShell version / edition it is configured to use (see this answer); to manage these settings, call Set-ExecutionPolicy from the respective version / edition, as a one-time configuration step.

For instance, to persistently set the policy for the current user to RemoteSigned, run
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

If you want to override the persistently configured policy in Visual Studio Code, add a Set-ExecutionPolicy command to the $PROFILE file as used by the PowerShell extension:

From the PowerShell Integrated Console, execute psedit $PROFILE to open the file for editing.
Add Set-ExecutionPolicy -Scope Process RemoteSigned to the file.
However, it can be problematic to have PowerShell act differently depending on whether it is run in the PIC (PowerShell-Integrated Console) that the PowerShell extension provides vs. running PowerShell as a regular shell in VSCode's integrated terminal or a regular console window / Windows Terminal tab.
The same goes for configuring PowerShell as a regular shell differently for VSCode's integrated terminal, by way of a custom shell profile, as shown in browser-bug's answer.

As for your question:

Since HKEY_CLASSES_ROOT is a composite view of HKEY_CURRENT_USER\Software\Classes and HKEY_LOCAL_MACHINE\Software\Classes, there is only one entry in this case, which you can access with either key path.

This entry, however, does not control the persistent execution policies for Windows PowerShell; instead, it is a convenience context-menu command definition that allows you to execute a *.ps1 file directly from File Explorer or the desktop. As a security feature, the command ensures that the execution policy in effect for the process being created only (-Scope Process) is at least as restrictive as RemoteSigned.

[1] Optional reading: Where PowerShell editions store their (non-GPO) persistent execution-policy settings:

^{The following applies to Windows only, because execution policies are fundamentally unsupported on Unix-like platforms.}

Note:

As shown in you question, execute Get-ExecutionPolicy -List lists all the policies in effect across scopes:
Settings in more specific scopes - if defined - take precedence; that is, the most specific scope that doesn't state Undefined is the one in effect for the process at hand.
Group policies (GPO-based settings) - i.e., scopes UserPolicy and MachinePolicy, which cannot be set with Set-ExecutionPolicy - can override the CurrentUser, LocalMachine, and Process scopes; notably, this means that even ad-hoc attempts to override the execution policy via -Scope Process Bypass / the -ExecutionPolicy Bypass CLI parameter may be prevented.
You should use Set-ExecutionPolicy to change the persistent settings rather than modifying these locations directly.

PowerShell [Core] (version 6 or higher) stores the settings in .json files:

Current-user policy (Scope -CurrentUser; file may not exist):
- "$([Environment]::GetFolderPath('MyDocuments'))/powershell/powershell.config.json"
Machine policy (Scope -LocalMachine):
- "$PSHOME\powershell.config.json"
- Note that the filename root is powershell, even though the actual executable filename root is pwsh:

Windows PowerShell (version up to 5.1) stores the settings in the registry (keys won't exist, if you've never run Set-ExecutionPolicy or if you run Set-ExecutionPolicy to set a scope's policy to Undefined):

Current-user policy (-Scope CurrentUser): HKCU:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell, value ExecutionPolicy
- Both the 32-bit and the 64-bit PowerShell executables see the same value, because there are no bit-ness-specific hives for HKCU (HKEY_CURRENT_USERS).
Machine policy (-Scope LocalMachine): HKLM:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell, value ExecutionPolicy
- Caveat: The 32-bit and the 64-bit executables see distinct values, because 32-bit applications have a separate HKEY_LOCAL_MACHINE\Software hive.