"Running Scripts Is Disabled on This System" in PowerShell: What It Means and the Safe Fixes (Tested on Windows 11)
You double-click a .ps1 and it opens in Notepad, or you run it in PowerShell and get a red block of text ending in about_Execution_Policies. Sometimes it is not even your script: typing npm in PowerShell can fail the same way. The cause is PowerShell's execution policy, and there are two different errors that people mix up. I reproduced both on a Windows 11 PC with Windows PowerShell 5.1, checked what each fix actually changes, and kept to the ones that don't switch the safety check off for good.
The two errors, word for word
I made a one-line script, hello.ps1, and ran it in Windows PowerShell 5.1 (build 26100.9711) on Windows 11 under different policies. With the policy set to Restricted for that session, PowerShell refused it with this message (exit code 1):
.\hello.ps1 : File C:\...\hello.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.
+ CategoryInfo : SecurityError: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccessThen I copied the same script, added the Zone.Identifier stream that browsers attach to downloads (ZoneId=3, the internet zone), and ran it under RemoteSigned. Same script, different message:
File C:\...\downloaded.ps1 cannot be loaded. The file C:\...\downloaded.ps1 is not digitally signed. You cannot run this script on the current system. For more information about running scripts and setting execution policy, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.The link in the English message really is printed as https:/go.microsoft.com with one slash, which is why people search for "https /go.microsoft.com/fwlink/ linkid 135170". It points to Microsoft's about_Execution_Policies page.
What the execution policy is (and isn't)
Microsoft's about_Execution_Policies describes the policy as a safety feature that controls when PowerShell loads configuration files and runs scripts. Two lines from that page are worth knowing before you change anything:
- Restricted is the default on Windows client computers and RemoteSigned on Windows Server. Restricted permits individual commands but no scripts at all.
- The policy "isn't a security boundary" - it is there so users don't run scripts unintentionally. Treat a script from the internet as a program you are about to run, whatever the policy says.
The policy can be set at five scopes, and the most specific one wins: MachinePolicy and UserPolicy (Group Policy), then Process (this session only), CurrentUser, and LocalMachine. You can see all of them with:
Get-ExecutionPolicy -ListOn my test PC this showed LocalMachine RemoteSigned and everything else Undefined - so it was not at the factory default; something had set RemoteSigned for the whole machine earlier. That is why I forced Restricted per session for the tests instead of changing the PC's setting.
Fix 1: run it once, change nothing
If you trust the script and only need to run it now, start PowerShell for that one file with a different policy:
powershell -ExecutionPolicy Bypass -File .\script.ps1My downloaded test script ran this way. Afterwards a fresh PowerShell window still listed Process Undefined and LocalMachine RemoteSigned - nothing was written to the registry. Inside an already-open window, Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force does the same for that window only; Microsoft notes it is kept in the $Env:PSExecutionPolicyPreference variable and disappears when the session closes.
Child processes inherit it. My first test round ran from a PowerShell that had been started with Bypass, and the "downloaded" script ran without complaint - the child powershell.exe had picked up Bypass from the parent. If a script runs on one machine and not another, check how the parent shell was started.
Fix 2: allow your own scripts permanently (RemoteSigned for your account)
If you write or run scripts regularly, Microsoft's documented setting is RemoteSigned for the current user:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUserAccording to the same page, this is stored under HKCU (your account only), takes effect immediately, and only the LocalMachine scope needs PowerShell run as administrator. Under RemoteSigned, scripts written on your PC run, and scripts downloaded from the internet must be signed - or unblocked. I did not change this PC's own setting for the article; the RemoteSigned behaviour above was measured with the policy it already had.
Two things to avoid: setting Unrestricted or Bypass permanently (nothing is checked any more), and changing LocalMachine when CurrentUser is enough. If Group Policy sets the policy (a work or school PC), Get-ExecutionPolicy -List shows a value in MachinePolicy or UserPolicy and your change won't take effect - that's for the administrator.
Fix 3: "is not digitally signed" - unblock that one file
When the policy is already RemoteSigned and only a downloaded script fails, you don't need to touch the policy. Read the script first, then remove the internet mark:
Unblock-File -Path .\script.ps1On my test file, Get-Item .\downloaded.ps1 -Stream * listed :$DATA and Zone.Identifier before, and only :$DATA after; the script then ran under RemoteSigned with exit code 0. Microsoft also notes that files fetched with curl.exe, Invoke-WebRequest or Invoke-RestMethod may not get the mark at all - so "it ran" is not proof the file is safe.
When it's npm: npm.ps1 cannot be loaded
Node.js puts three npm launchers in C:\Program Files\nodejs: npm (for Bash), npm.cmd and npm.ps1. In PowerShell, Get-Command npm resolved to npm.ps1 on this PC (Node v24.13.0), so under Restricted npm -v failed with "npm.ps1 cannot be loaded because running scripts is disabled on this system".
npm.cmd -v printed 11.6.2 under the same Restricted session - the .cmd launcher isn't a PowerShell script. Use npm.cmd (and npx.cmd) as a quick workaround, or set RemoteSigned for your account as in Fix 2 so npm.ps1 runs.
Other things that look like the same problem
| What you see | Cause (checked on this PC) | What to do |
|---|---|---|
| Double-clicking a .ps1 opens Notepad | The .ps1 file type was set to open in Notepad | Right-click → Run with PowerShell, or run it from a PowerShell window |
| 'hello.ps1' is not recognized as the name of a cmdlet… | Typed the name without .\ - PowerShell doesn't run scripts from the current folder by name | Type .\hello.ps1 |
| The window flashes and closes | The Run with PowerShell command here is powershell.exe -file "%1" with no -NoExit | Run it from an open PowerShell window to read the output |
| Works in one window, not in another | A Process-scope policy (inherited from a parent shell) differs | Compare Get-ExecutionPolicy -List in both |
The Run with PowerShell command has no -ExecutionPolicy switch on this build, so it follows the same policy as everything else. PowerShell 7 (pwsh) wasn't installed on this PC, so I didn't test it.
FAQ
Q. Is it safe to run Set-ExecutionPolicy Unrestricted?
It removes the check for every script on the account or machine, including downloaded ones (Unrestricted only warns). Microsoft describes RemoteSigned as allowing local scripts while requiring signatures on downloaded ones, which is usually all you need. Use Bypass for a single run instead of making it permanent.
Q. Do I need to run PowerShell as administrator?
Not for -Scope CurrentUser or -Scope Process. Microsoft's page says administrator rights are needed to change the LocalMachine scope.
Q. I changed the policy but it still says scripts are disabled.
Run Get-ExecutionPolicy -List. A value in MachinePolicy or UserPolicy comes from Group Policy and overrides your setting; a Process value in that window also wins over CurrentUser.
Q. Why does npm work in Command Prompt but not in PowerShell?
cmd runs npm.cmd, which isn't affected by the execution policy. PowerShell picks npm.ps1 first, which is. Typing npm.cmd in PowerShell worked on this PC under Restricted.
Comments 0
No comments yet. Be the first.
Only members can comment.
Comments with ads, abuse, personal information or illegal content are hidden or removed. Members who post ads, spam, or hateful content are removed from the site, and everything they wrote is deleted. Comments are shown with your nickname. Privacy Policy