vscode-powershell | Provides PowerShell language and debugging support | Command Line Interface library

Ok, I figured the issue out myself. Following the advice of this tweet I updated my PowerShell Profile to include $PSDefaultParameterValues.Add("Get-Help:Online", $true). It looks like the PowerShell extension calls the Get-Help cmdlet in order to populate intellisense and tooltips. This was resulting in the intellisense and tooltips launching the help in an external browser window. The solution was to remove the line from my PowerShell Profile.

I tracked down the repo where the bug is actually occurring and reported the issue there, and opened a pull request to fix it, so it should be fixed in future versions of VS Code once they take the change :)

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, use Set-ExecutionPolicy from the respective version / edition.

• 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.

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.