Fix PowerShell Execution Policy: Scripts Cannot Be Loaded
─□✕

Fix PowerShell Execution Policy: Scripts Cannot Be Loaded

PowerShell Tips Editor 4 min read
Fix PowerShell Execution Policy: Scripts Cannot Be Loaded

You double-click a PowerShell script and get hit with: “cannot be loaded because running scripts is disabled on this system.” This is the PowerShell execution policy scripts cannot be loaded error — and it stops every new PowerShell user cold. The good news: it’s a security feature with a deliberate, safe fix that takes about 30 seconds. This guide explains what execution policies are, which one to use, and how to set it correctly without compromising your system.

Quick Answer / TL;DR

Run PowerShell as Administrator and set the policy for your current user:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

What Is the Execution Policy and Why Does It Exist

The execution policy is a safety feature — not a security boundary — that controls whether PowerShell runs script files. Microsoft designed it to prevent accidental script execution, not to stop a determined attacker. The policy gates .ps1 files specifically; it does not restrict interactive commands typed at the prompt.

Think of it as a seatbelt: it reduces accidental harm but doesn’t make you bulletproof. You should still audit scripts before running them, especially scripts downloaded from the internet or received by email.

Understanding the Four Policy Levels

PowerShell has five execution policy values, but four are commonly used:

  • Restricted — No scripts run at all. Default on Windows client OS. Interactive commands still work.
  • AllSigned — Only scripts signed by a trusted publisher run. Strong security, but impractical unless you sign everything.
  • RemoteSigned — Locally written scripts run freely. Scripts downloaded from the internet must be signed. Recommended for most users.
  • Unrestricted — All scripts run, but scripts from the internet show a warning prompt. Avoid on shared machines.
  • Bypass — Everything runs, no warnings, no prompts. Used inside larger automation systems, not interactively.

How to Check Your Current Policy

Before changing anything, see what is currently set at each scope:

Get-ExecutionPolicy -List
        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser       Undefined
 LocalMachine      Restricted

Policies are evaluated from top to bottom. The first non-Undefined scope wins. MachinePolicy and UserPolicy come from Group Policy and override everything else.

Setting the Policy with Set-ExecutionPolicy

The safest change is at the CurrentUser scope — it only affects you and does not require administrator rights:

# Safe: changes only for the current user
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

# Verify it took effect
Get-ExecutionPolicy -Scope CurrentUser
RemoteSigned

To set it machine-wide (requires admin):

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

Note that LocalMachine affects all users on the computer. Prefer CurrentUser unless you’re deploying to a managed endpoint.

Bypass Policy for a Single Script

If you can’t or don’t want to change the persistent policy, bypass it for a single execution using the -ExecutionPolicy flag when launching PowerShell:

# Run a specific script without changing the persistent policy
powershell -ExecutionPolicy Bypass -File "C:\Scripts\MyScript.ps1"

You can also unblock a downloaded file. Windows marks internet-sourced files with an Alternate Data Stream (Zone.Identifier). Unblock-File removes that mark:

Unblock-File -Path "C:\Downloads\ImportedScript.ps1"

Group Policy Overrides and IT Restrictions

If Set-ExecutionPolicy appears to work but scripts still won’t run, check whether Group Policy is enforcing a policy at the MachinePolicy or UserPolicy scope. These come from your Active Directory domain and override local settings:

Get-ExecutionPolicy -List | Where-Object { $_.ExecutionPolicy -ne 'Undefined' }

If you see a value at MachinePolicy or UserPolicy, contact your IT administrator — you cannot override Group Policy from PowerShell. In that environment, the standard approach is to use powershell -ExecutionPolicy Bypass -File script.ps1 as part of a deployment tool that already runs with appropriate rights.

Common Errors and Fixes

  • Set-ExecutionPolicy fails without admin rights: If you’re setting the LocalMachine scope, you need an elevated session. Either right-click PowerShell and run as Administrator, or switch to the CurrentUser scope which does not require elevation.
  • Policy set in wrong scope: Setting LocalMachine when a CurrentUser or Process scope already exists means the higher-priority scope wins. Always run Get-ExecutionPolicy -List after changing to confirm the effective policy.

Related Cmdlets / See Also

Wrapping Up

The execution policy error is common and easy to fix: run Set-ExecutionPolicy RemoteSigned -Scope CurrentUser and your scripts will run. Use Get-ExecutionPolicy -List to understand which scope is winning before you change anything, and remember that Group Policy always takes precedence over local settings. Next step: open PowerShell as Administrator and run that command right now.

#bypass#error#execution-policy#security
Send-Item -To