Running Scripts Is Disabled on This System? How to Fix It

The PowerShell error “running scripts is disabled on this system” means the active execution policy will not allow a .ps1 file to run. It often appears when you activate a Python virtual environment, run npm in Visual Studio Code, launch a downloaded script, or load a PowerShell profile.

A typical message looks like this:

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

On a personal Windows 11 PC, this command is often the right long-term fix:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Do not run it blindly, though. A downloaded script, a temporary task, and a work-managed computer each call for a different response. The safest approach is to identify which policy is actually blocking the script and make the narrowest change that solves the problem.

Choose the Right Fix for Your Situation

Situation	Best starting point	Why
You regularly run scripts you write yourself	Set RemoteSigned for CurrentUser	It affects only your account and permits local scripts
One trusted downloaded script is blocked	Review it, then use Unblock-File	It changes that file instead of weakening policy for every script
You need a trusted script for one terminal session	Set Bypass for Process	The change disappears when that PowerShell process closes
npm.ps1 or Python Activate.ps1 is blocked	Use RemoteSigned for ongoing development or Process for a temporary session	Both preserve a limited scope
The PC belongs to a company or school	Check MachinePolicy and UserPolicy	An administrator may be enforcing the setting
You changed the policy but the error remains	Check the exact PowerShell edition and all scopes	Windows PowerShell 5.1 and PowerShell 7 are managed separately

Avoid setting Bypass or Unrestricted permanently for the whole computer. Those commands are broader than most home users need.

Check Which Execution Policy Is Blocking the Script

Open the same PowerShell terminal in which the error appears and run:

Get-ExecutionPolicy

This shows the effective policy for that session. Next, display every scope:

Get-ExecutionPolicy -List

You may see output similar to this:

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

PowerShell uses the first defined policy in this order:

1. MachinePolicy
2. UserPolicy
3. Process
4. CurrentUser
5. LocalMachine

For example, CurrentUser set to RemoteSigned cannot override MachinePolicy set to AllSigned. Microsoft describes execution policy as a safety feature and defense-in-depth measure, not a security boundary. The official PowerShell execution-policy documentation explains each policy and its precedence.

Fix 1: Use RemoteSigned for Regular Personal Scripts

For a personal development PC, RemoteSigned at the CurrentUser scope is usually the most practical lasting option.

Run:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Press Y, then Enter if PowerShell asks for confirmation. Verify the result:

Get-ExecutionPolicy -List

CurrentUser affects only your Windows account and normally does not require administrator permission. RemoteSigned allows scripts created locally to run. A script marked as downloaded from the internet must still be signed by a trusted publisher or deliberately unblocked.

The scope is important. Running Set-ExecutionPolicy RemoteSigned without -Scope targets LocalMachine by default, affects every user, and requires an elevated terminal. That is unnecessary for many personal scripting tasks.

Try the script again using . when it is in the current folder:

.\script.ps1

For a path containing spaces, use the call operator:

& "C:\My Scripts\script.ps1"

PowerShell does not automatically search the current folder for commands. A policy error and a later “not recognized” error are therefore separate problems.

Fix 2: Unblock One Trusted Downloaded Script

A script can remain blocked under RemoteSigned because Windows marked it as coming from the internet. Unblock it only after reading the code and confirming that you trust its source.

First, check its signature when one is expected:

Get-AuthenticodeSignature -FilePath "C:\Scripts\script.ps1"

You can also open the file in Notepad or Visual Studio Code and review what it does. Be especially cautious if it disables security tools, downloads and executes more code, creates scheduled tasks, deletes folders recursively, or uses Invoke-Expression on downloaded text.

After reviewing it, unblock only that file:

Unblock-File -Path "C:\Scripts\script.ps1"

Alternatively, right-click the file in File Explorer, select Properties, check Unblock on the General tab, and select Apply.

Unblock-File removes the internet-zone marker. It does not verify the script or make malicious code safe. Microsoft’s Unblock-File documentation provides the command’s current behavior and examples.

When the script came from a ZIP archive

Files extracted from a downloaded ZIP can inherit its internet marker. For a trusted archive, scan and inspect it, open the ZIP’s Properties window, select Unblock if present, and then extract it again.

Do not recursively unblock your Downloads folder or an unfamiliar software package. That removes a useful warning from many files at once.

Fix 3: Make a Temporary Change for One Session

For a trusted script needed only once, set the policy for the current PowerShell process:

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process

Run the script, then close that terminal when finished. The Process setting is held only for that PowerShell session and its child processes.

This is narrower than setting Bypass for CurrentUser or LocalMachine, but it removes execution-policy checks for every script launched in that session. Do not paste or run code you have not reviewed.

You can also launch one script in a separate process.

For Windows PowerShell 5.1:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File "C:\Scripts\script.ps1"

For PowerShell 7:

pwsh.exe -NoProfile -ExecutionPolicy Bypass -File "C:\Scripts\script.ps1"

-NoProfile prevents a separate profile script from loading in the new process. Neither command overrides an execution policy enforced through Group Policy.

Fix npm.ps1 in Visual Studio Code

Node.js installs a PowerShell command shim named npm.ps1. When it is blocked, a command such as npm install can produce the execution-policy error even though npm itself is installed correctly.

For regular development on a personal PC, set:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Terminate the existing Visual Studio Code terminal using the trash icon, open a new PowerShell terminal, and test:

npm --version

For a one-command workaround, call the Command Prompt shim:

npm.cmd install

Do not delete npm.ps1. Removing package-manager files can cause a different failure after Node.js is updated or repaired.

Fix Python Activate.ps1

A Python virtual environment uses a PowerShell activation script:

.\.venv\Scripts\Activate.ps1

For ongoing development, use RemoteSigned at CurrentUser. For one session only, run:

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process
.\.venv\Scripts\Activate.ps1

You can instead open Command Prompt and use its batch-file activator:

.venv\Scripts\activate.bat

That uses a different shell and does not run the PowerShell activation script. The differences between these shells are covered in Windows PowerShell vs Command Prompt.

When Set-ExecutionPolicy Appears Not to Work

Work through these checks in order.

Check for organization policy

Run:

Get-ExecutionPolicy -List

If MachinePolicy or UserPolicy has a value, it overrides Process, CurrentUser, and LocalMachine. A local command may report that it updated your preference while warning that Group Policy still controls the effective policy.

Do not try to defeat security controls on a work or school computer. Give the administrator the full error, script source, reason it is required, and output from Get-ExecutionPolicy -List.

Check the PowerShell edition

Run:

$PSVersionTable.PSEdition
$PSVersionTable.PSVersion

Windows PowerShell 5.1 uses powershell.exe, while PowerShell 7 uses pwsh.exe. Microsoft states that these editions store execution-policy settings separately. Make the change in the edition that reports the error, then verify it there with Get-ExecutionPolicy -List.

Start without a profile

When the error appears every time PowerShell opens, a profile script may be blocked. Start a clean session:

powershell.exe -NoProfile

or:

pwsh.exe -NoProfile

If the clean session works, display the profile path with $PROFILE, review that file, and unblock it only if you trust its contents.

Separate policy errors from Windows corruption

Execution policy normally blocks scripts and profiles, not interactive commands such as Get-Date or Get-Process. If basic cmdlets fail too, the problem may be a damaged profile, installation, module, PATH value, or Windows component. That broader case may require the checks in Windows Resource Protection error rather than another execution-policy change.

Restore the Previous Setting

Before changing a policy, save or copy the output from:

Get-ExecutionPolicy -List

To remove the setting you added at CurrentUser, run:

Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope CurrentUser

Undefined removes the policy from that scope. It does not force the entire computer to use an undefined policy. PowerShell falls through to the next defined scope, or to the Windows client default when no scope has a value.

Commands to Avoid as a Default Fix

Do not copy these as a general solution:

Set-ExecutionPolicy Unrestricted -Scope LocalMachine
Set-ExecutionPolicy Bypass -Scope CurrentUser

They weaken checks more broadly and for longer than the usual problem requires. Execution policy is not antivirus protection, but its warnings can still prevent accidental script execution.

Use RemoteSigned at CurrentUser for regular personal scripting, Unblock-File for one reviewed download, or Bypass at Process for a temporary trusted task. On a managed computer, let the administrator decide whether the script meets the organization’s requirements.