Fix: PowerShell Script Cannot Be Loaded Because Running Scripts Is Disabled

The Error

You try to run a PowerShell script and get:

.\script.ps1 : File C:\Users\you\script.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 : UnauthorizedAccess

Or one of these variations:

File C:\path\to\script.ps1 cannot be loaded. The file C:\path\to\script.ps1 is not digitally signed.
The script will not run on the system.

.\deploy.ps1 : File C:\deploy.ps1 cannot be loaded because running scripts is disabled on this system.

Install-Module : Scripts are not allowed to run on this system.

This also blocks commands like npm, yarn, ng, vue, or tsc if they rely on .ps1 wrapper scripts in your PATH.

Why This Happens

PowerShell has a built-in security feature called the execution policy. It controls whether PowerShell scripts (.ps1 files) are allowed to run on the system. The execution policy is not a security boundary — Microsoft’s own documentation says it’s designed to prevent users from accidentally running scripts, not to lock down the system against attackers.

There are five execution policy levels:

On a fresh Windows 10 or 11 install, the execution policy is set to Restricted. That means every .ps1 script is blocked, including scripts you wrote yourself.

The execution policy can be set at multiple scopes, and they override each other in a specific order:

1. MachinePolicy — Set by Group Policy for the computer. Highest priority.
2. UserPolicy — Set by Group Policy for the user.
3. Process — Applies only to the current PowerShell session.
4. CurrentUser — Applies to the current user account. Stored in the registry.
5. LocalMachine — Applies to all users on the computer. Stored in the registry.

PowerShell evaluates these scopes from top to bottom and uses the first one that is not Undefined. If a Group Policy scope is set, it overrides everything below it — and you cannot change it with Set-ExecutionPolicy.

Check your current execution policy and all scopes:

Get-ExecutionPolicy
Get-ExecutionPolicy -List

The output of Get-ExecutionPolicy -List shows all five scopes and their current values. This tells you exactly where the restriction is coming from.

Fix 1: Set the Execution Policy for Your User

The cleanest fix for most developers. This changes the policy for your user account only and persists across sessions:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

You do not need administrator privileges for this command because CurrentUser scope writes to HKEY_CURRENT_USER in the registry.

RemoteSigned is the recommended policy for developers. It allows you to run any script you create locally while still requiring downloaded scripts to have a valid digital signature. This strikes a good balance between convenience and safety.

After running this command, try your script again:

.\script.ps1

If you want to verify the change took effect:

Get-ExecutionPolicy -Scope CurrentUser

Pro Tip: Avoid setting the policy to Unrestricted unless you have a specific reason. RemoteSigned gives you the same flexibility for local scripts while still flagging potentially dangerous downloaded files. Many corporate security audits flag Unrestricted policies as a finding.

Fix 2: Set the Execution Policy for All Users (Requires Admin)

If you need every user account on the machine to run scripts, set the policy at the LocalMachine scope. Open PowerShell as Administrator (right-click the PowerShell icon and select “Run as administrator”):

Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy RemoteSigned

This writes to HKEY_LOCAL_MACHINE in the registry and applies to all users. You must have admin rights because it affects the entire machine.

If you get a prompt asking for confirmation, type Y and press Enter. To skip the prompt in automated scenarios:

Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy RemoteSigned -Force

Note: If a CurrentUser policy is already set, it takes precedence over LocalMachine for that specific user. Check both scopes with Get-ExecutionPolicy -List if your script still fails after this change.

Fix 3: Bypass the Policy for a Single Script

Sometimes you need to run one script without permanently changing any policy. Use the -ExecutionPolicy Bypass flag when launching PowerShell:

powershell -ExecutionPolicy Bypass -File .\script.ps1

Or from within an already-open PowerShell session, set the policy for just the current process:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\script.ps1

The Process scope only lasts for the current session. Once you close that PowerShell window, the policy reverts to whatever is set at higher scopes. This is useful for one-off tasks or when you do not want to change any persistent settings.

You can also use this approach in batch files, scheduled tasks, or CI/CD pipelines:

powershell.exe -ExecutionPolicy Bypass -File "C:\scripts\deploy.ps1"

This is similar to how you might handle permission issues in bash where you use sudo or chmod for one-time execution rather than changing system-wide settings.

Fix 4: Unblock a Downloaded Script

When you download a .ps1 file from the internet (via a browser, email attachment, or Invoke-WebRequest), Windows attaches an Alternate Data Stream called Zone.Identifier to the file. This marks the file as coming from the internet. Even with RemoteSigned policy, PowerShell blocks these files unless they are digitally signed.

Check if a file is blocked:

Get-Item .\script.ps1 -Stream Zone.Identifier

If the stream exists, unblock the file:

Unblock-File .\script.ps1

To unblock all .ps1 files in a directory:

Get-ChildItem -Path C:\scripts -Filter *.ps1 | Unblock-File

You can also unblock via the Windows GUI: right-click the file, select Properties, and check the Unblock checkbox at the bottom of the General tab.

Note: Unblock-File only removes the zone identifier. It does not change the execution policy itself. You still need at least RemoteSigned as your policy.

Fix 5: Fix Group Policy Restrictions

If Get-ExecutionPolicy -List shows a value under MachinePolicy or UserPolicy, the execution policy is being enforced by Group Policy. You cannot override it with Set-ExecutionPolicy:

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

In this scenario, running Set-ExecutionPolicy gives you:

Set-ExecutionPolicy : Windows PowerShell updated your execution policy successfully, but the setting is
overridden by a policy defined at a more specific scope.

To fix this, you need to change or remove the Group Policy setting:

1. Open the Group Policy Editor (gpedit.msc) as an administrator.
2. Navigate to Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell.
3. Double-click Turn on Script Execution.
4. Set it to Not Configured (to remove the restriction) or Enabled and select your preferred policy.
5. Run gpupdate /force in an elevated command prompt to apply the change immediately.

If your machine is domain-joined, the Group Policy may come from your organization’s domain controller. In that case, contact your IT administrator — you cannot change domain-level policies locally.

As a workaround when Group Policy blocks you but you still need to run a script, use the Process scope bypass from Fix 3. Group Policy applies to MachinePolicy and UserPolicy scopes, but some configurations still allow Process-level overrides. This is analogous to how environment variable issues can stem from system-level settings overriding user-level ones.

Fix 6: Sign Your PowerShell Scripts

If your organization requires AllSigned policy, you need to digitally sign your scripts. This is common in enterprise environments where security policies mandate code signing.

Create a self-signed certificate (for development and internal use):

$cert = New-SelfSignedCertificate -Type CodeSigningCert -Subject "CN=Dev Script Signing" -CertStoreLocation Cert:\CurrentUser\My

Sign your script with the certificate:

$cert = Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert | Select-Object -First 1
Set-AuthenticodeSignature -FilePath .\script.ps1 -Certificate $cert

Verify the signature:

Get-AuthenticodeSignature .\script.ps1

The output should show Valid as the status.

For the AllSigned policy to accept a self-signed certificate, you must also add it to the Trusted Publishers and Trusted Root Certification Authorities stores:

Export-Certificate -Cert $cert -FilePath C:\temp\dev-signing.cer
Import-Certificate -FilePath C:\temp\dev-signing.cer -CertStoreLocation Cert:\CurrentUser\TrustedPublisher
Import-Certificate -FilePath C:\temp\dev-signing.cer -CertStoreLocation Cert:\CurrentUser\Root

Common Mistake: If you edit a signed script after signing it, the signature becomes invalid and PowerShell blocks the script again. You must re-sign the script every time you make changes. In active development, this workflow is impractical — consider using RemoteSigned for your development machine and AllSigned only in production.

For production environments, use a certificate from a trusted Certificate Authority (CA) or your organization’s internal PKI instead of a self-signed certificate.

Fix 7: Fix the Policy in VS Code, Windows Terminal, or ISE

Different terminal hosts can have their own execution policy quirks.

VS Code Integrated Terminal

VS Code sometimes sets its own execution policy for the integrated terminal. If scripts work in a standalone PowerShell window but fail in VS Code:

1. Open VS Code Settings (Ctrl+,).
2. Search for terminal.integrated.shellArgs.windows.
3. Add -ExecutionPolicy RemoteSigned to the shell arguments.

Or add this to your settings.json:

{
  "terminal.integrated.profiles.windows": {
    "PowerShell": {
      "source": "PowerShell",
      "args": ["-ExecutionPolicy", "RemoteSigned"]
    }
  }
}

PowerShell Profile Script

Your PowerShell profile ($PROFILE) might be setting the execution policy. Check if a profile exists and what it contains:

Test-Path $PROFILE
Get-Content $PROFILE

If the profile contains Set-ExecutionPolicy Restricted or similar, remove or change that line. The profile path is typically C:\Users\<username>\Documents\PowerShell\Microsoft.PowerShell_profile.ps1 for PowerShell 7+ or C:\Users\<username>\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 for Windows PowerShell 5.1.

PowerShell ISE vs PowerShell Console

Windows PowerShell ISE and the PowerShell console can have different execution policies. ISE uses the same policy scopes, but check both environments if you see inconsistent behavior:

# In ISE
Get-ExecutionPolicy -List

# In regular PowerShell
Get-ExecutionPolicy -List

Fix 8: Fix npm, yarn, and CLI Tool Errors Caused by Execution Policy

Many Node.js CLI tools install .ps1 wrapper scripts in your npm global directory. When PowerShell is set to Restricted, commands like npm, yarn, ng, tsc, vue, vite, and eslint all fail with the “running scripts is disabled” error.

The error looks like this:

ng : File C:\Users\you\AppData\Roaming\npm\ng.ps1 cannot be loaded because running scripts is disabled on this system.

The fix is the same as Fix 1 — set the execution policy to RemoteSigned:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

If the .ps1 files were downloaded via npm (which they were), they may also have the zone identifier attached. Unblock the entire npm scripts directory:

Get-ChildItem -Path "$env:APPDATA\npm" -Filter *.ps1 | Unblock-File

Alternatively, you can delete the .ps1 files and rely on the .cmd wrappers instead. npm installs both:

Remove-Item "$env:APPDATA\npm\ng.ps1"

The .cmd version runs without any execution policy restrictions because .cmd files are not subject to PowerShell’s execution policy — they run through cmd.exe. However, this is a workaround, not a fix. The proper solution is setting RemoteSigned as shown above.

This is a different class of problem from Node.js module resolution errors or npm EACCES permission issues, but it can produce similarly confusing error messages when CLI tools suddenly stop working.

Still Not Working?

If you have tried the fixes above and scripts still fail, work through these checks:

Check Which PowerShell Version You Are Running

Windows ships with Windows PowerShell 5.1 (powershell.exe), but many developers also install PowerShell 7+ (pwsh.exe). These are separate installations with separate execution policies and separate profiles.

$PSVersionTable.PSVersion

If you set the policy in one version but run your script in the other, the change has no effect. Set the policy in both:

# In Windows PowerShell 5.1
powershell -Command "Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned"

# In PowerShell 7+
pwsh -Command "Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned"

Check for Registry Corruption

The execution policy is stored in the registry. Corrupted entries can cause unexpected behavior. Check the registry values directly:

# LocalMachine scope
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell" -Name ExecutionPolicy -ErrorAction SilentlyContinue

# CurrentUser scope
Get-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell" -Name ExecutionPolicy -ErrorAction SilentlyContinue

If a value is set to something unexpected, remove it and set the policy again:

Remove-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell" -Name ExecutionPolicy
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

Check for Third-Party Security Software

Antivirus software, endpoint protection tools (CrowdStrike, Carbon Black, Symantec Endpoint Protection), and Windows Defender Application Control (WDAC) can block script execution independently of the PowerShell execution policy. If Get-ExecutionPolicy -List shows the correct settings but scripts still fail:

• Check your antivirus logs for blocked script events.
• Temporarily disable real-time protection to confirm if the AV is the cause.
• Add your script directory to the exclusion list if confirmed.

This is conceptually similar to how SSL certificate errors can come from corporate proxy software intercepting connections rather than from the actual application configuration.

Verify the Script File Is Not Corrupted

If a script runs for other users but not for you, the file itself might have encoding issues or hidden characters:

# Check encoding
Get-Content .\script.ps1 -Encoding Byte | Select-Object -First 10

PowerShell scripts should be UTF-8 (with or without BOM) or UTF-16 LE. Other encodings can cause parsing failures that look like execution policy errors.

Run a Direct Policy Test

Create a minimal test script to isolate the problem:

"Hello from test script" | Out-File test-policy.ps1
.\test-policy.ps1
Remove-Item test-policy.ps1

If this minimal script works but your actual script fails, the problem is in the script itself, not the execution policy. Check for syntax errors, missing modules, or permission issues on the directories the script accesses.