On Windows 10, the Windows PowerShell Run with PowerShell shortcut menu command (defined in the registry) attempts a process-specific execution policy override via the CLI, by calling Set-ExecutionPolicy -Scope Process Bypass as part of code passed to the -Command parameter.
However, because your machine's execution policy is governed by a GPO (Group Policy Object), as indicated by the MachinePolicy output line having a value other than Undefined, neither overrides via the CLI's -ExecutionPolicy parameter nor via Set-ExecutionPolicy are effective.
This is what the error message is trying to tell you; specifically, it means: I applied the change you requested, but it has no effect.
- As an aside: It is unfortunate that what should be a warning is surfaced as an error, but it was decided not to change that in the interest of backward compatibility; see GitHub issue #12032
The error itself does not stop execution, which continues with the GPO-controlled policy in effect.
Given that the effective GPO policy is Unrestricted in your case (which should probably be RemoteSigned for better security), your scripts will still execute and you can ignore the error message.
To make the error message go away, one option is to remove the Set-ExecutionPolicy call from the command definition in the registry.
Its modification requires elevation, i.e. administrative privileges, due to being in the HKEY_LOCAL_MACHINE registry hive; however, it is possible to define user-specific equivalents in the HKEY_CURRENT_USER hive, which therefore do not require elevation - see below.
The other option is to deactivate the relevant GPO, which - given that it is the MachinePolicy - at the very least requires elevation too, but is typically not under your control in a domain environment.
Modifying / overriding the command to omit the Set-Execution call and therefore suppress the warning:
On Windows 10, the following should work (I cannot personally verify any longer), based on the information in the bottom section of this answer, adapted to target whatever file type is currently registered for .ps1 files, which may differ from the default, notably if you have Visual Studio Code installed:
# Determine the registry key path, based on the HKEY_CURRENT_USER
# equivalent of the file-type key.
$regKey = 'registry::HKEY_CURRENT_USER\Software\Classes\{0}\shell\Run with PowerShell\Command' -f (Get-ItemPropertyValue registry::HKEY_CLASSES_ROOT\.ps1 '(Default)')
# Create the key, if necessary.
if (-not (Test-Path $regKey)) { $null = New-Item -Force -ErrorAction Stop $regKey }
# Define the command line, without Set-ExecutionPolicy and with -NoExit.
Set-ItemProperty $regKey '(Default)' '"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoExit -File "%1"'
This creates a HKEY_CURRENT_USER equivalent of the (potentially) HKEY_LOCAL_MACHINE-housed shortcut-menu command definition, which should override the latter, given that the HKEY_CLASSES_ROOT hive, through which the shortcut-menu definitions are loaded, is a composite view of the former two hives' Software\Classes paths, with the user-level definitions taking precedence.
Also note that -NoExit was added to keep the session alive after script execution and therefore the window open.
If you do have administrative privileges, you can replace HKEY_CURRENT_USER with HKEY_LOCAL_MACHINE in the code above and run it with elevation.
On Windows 11, the problem no longer arises, because the Windows PowerShell CLI call configured there no longer tries to change the execution policy.
However, you may still want to modify the call, namely to include the -NoExit switch too (to keep the session alive and the window open after script execution): see this answer.
In PowerShell (Core) 7 - which is no longer supported on Windows 10 - the problem also doesn't arise: no attempt is made to set the execution policy.
Fundamentally, the shortcut-menu commands are only available if you install PowerShell 7 via its MSI package, where you get the option to install commands for folders and drives, as well as for running individual *.ps1 files (as in Windows PowerShell).
To see them, you must hold down Shift while right-clicking.
The folder/drive-level commands (PowerShell 7 submenu) open an interactive session in the target folder or drive.
The *.ps1-file-level command, stored at HKEY_CLASSES_ROOT\Microsoft.PowerShellScript.1\Shell\PowerShell7x64\Command, as of PowerShell 7.4.3:
appears to be broken: at least on my machine, it is never shown.
is misdefined:
C:\Program Files\PowerShell\7\pwsh.exe -Command "$host.UI.RawUI.WindowTitle = 'PowerShell 7 (x64)'; & '%1'"- A fundamentally conceptual problem is that the executable path lacks
"..." enclosure, which is required to the path containing spaces - bizarrely, this is not in and of itself a problem (it also afflicts the folder/drive-level commands, which do work).
- The secondary problem is that enclosing a path in
'...' isn't robust, given that ' is a legal character in paths.
Even if it did work as intended, you may also want to modify it to include -NoExit, to prevent the window from auto-closing after script execution.
