PowerShell is a little like a professional kitchen knife: incredibly useful, surprisingly elegant, and absolutely capable of causing chaos if you swing it around without knowing what you are doing. One of the first “wait, why won’t this run?” moments many Windows users meet is the famous PowerShell execution policy error. You download a script, open PowerShell, type the command with confidence, and Windows replies with something that feels like a stern librarian: “running scripts is disabled on this system.”
The good news is that changing the PowerShell execution policy is usually simple. The better news is that you do not need to turn your computer into a script-running free-for-all just to get work done. In this guide, you will learn what the PowerShell execution policy is, how to check your current setting, how to change it safely, how scopes work, and what to do when Group Policy or corporate settings get in the way.
This article is written for Windows users, IT admins, developers, students, and anyone who has ever stared at a red PowerShell error message while wondering whether their computer has developed trust issues.
What Is the PowerShell Execution Policy?
The PowerShell execution policy is a safety feature that controls the conditions under which PowerShell loads configuration files and runs scripts. In plain English, it decides whether PowerShell should allow a script file, such as a .ps1 file, to run.
It is important to understand one thing right away: execution policy is not a full security system. It is not antivirus software. It is not a firewall. It is not a magical bouncer standing outside your PC wearing sunglasses. Microsoft describes it as a safety feature, not a security boundary. A determined user or attacker may bypass it, so you should treat it as one layer in a larger security approach.
Still, it is useful. Execution policy helps prevent accidental script execution, especially when users download files from the internet or run scripts they do not understand. That matters because PowerShell can automate system changes, manage files, modify registry settings, install software, and perform administrative tasks.
Common PowerShell Execution Policy Settings
Before changing anything, you should know what each policy means. Choosing the right option is better than randomly copying a command from the internet and hoping your laptop does not start making modem noises from 1998.
Restricted
Restricted is the most locked-down common policy. It prevents PowerShell scripts from running. You can still type individual commands directly into the console, but script files do not run. On many Windows client systems, this is the default behavior when no other policy is configured.
AllSigned
AllSigned allows scripts to run only if they are signed by a trusted publisher. This includes scripts created locally and scripts downloaded from the internet. It is stricter than RemoteSigned and is often used in more controlled business environments.
RemoteSigned
RemoteSigned is one of the most practical choices for personal computers and many development machines. It allows locally created scripts to run without a digital signature, but scripts downloaded from the internet must be signed by a trusted publisher. For many users, this is the sweet spot between convenience and caution.
Unrestricted
Unrestricted allows unsigned scripts to run. PowerShell may still warn you before running scripts downloaded from the internet, but this setting is far more permissive. It is not usually the best everyday choice unless you fully understand the risk and have a specific reason.
Bypass
Bypass means nothing is blocked and no warnings or prompts are displayed. This is commonly used for temporary automation scenarios, installers, or controlled deployment tools. It should not be your casual “set it and forget it” policy.
Undefined
Undefined means no execution policy is set for that scope. If every scope is undefined, Windows falls back to the default behavior, which is usually restrictive on Windows client systems.
How To Check Your Current PowerShell Execution Policy
Before you change the PowerShell execution policy, check the current setting. Open PowerShell and run:
This command shows the effective policy currently being applied. For example, you may see:
That means scripts are blocked under the effective policy. To see the policy for every scope, run:
You may see output similar to this:
This list is useful because PowerShell execution policies can be set at different levels. The effective policy depends on scope precedence, not simply the last command you ran.
Understanding PowerShell Execution Policy Scopes
Scopes determine where the policy applies. This is where many users get confused. They run Set-ExecutionPolicy, PowerShell says the command succeeded, and yet the policy still appears unchanged. That does not mean PowerShell is being dramatic. It usually means another scope has higher priority.
MachinePolicy
MachinePolicy is set by Group Policy for all users of the computer. This has the highest precedence. If your company manages your device, this may be controlled by your IT department.
UserPolicy
UserPolicy is also set by Group Policy, but it applies to the current user. It has high precedence and can override settings you try to configure manually.
Process
Process applies only to the current PowerShell session. When you close the session, the setting disappears. This is excellent when you need a temporary change.
CurrentUser
CurrentUser applies only to your user account. It does not require changing the policy for everyone on the machine and is often the safest practical scope for developers and regular users.
LocalMachine
LocalMachine applies to all users on the computer. Changing this scope usually requires running PowerShell as administrator.
How To Change The PowerShell Execution Policy Safely
The safest common approach for most individual users is to set the execution policy to RemoteSigned for the CurrentUser scope. This allows scripts you create locally to run while still adding protection for scripts downloaded from the internet.
Recommended Command for Most Users
Open PowerShell and run:
PowerShell may ask for confirmation. Type Y and press Enter.
If you want to skip the confirmation prompt, use:
This changes the policy only for your Windows user account. It does not affect other users on the same computer, which is polite behavior. Your computer has boundaries, and honestly, we respect that.
Change the Policy for All Users
If you are an administrator and want to set the execution policy for all users on the machine, open PowerShell as administrator and run:
To open PowerShell as administrator, search for PowerShell in the Start menu, right-click it, and choose Run as administrator. Without elevated permissions, changing LocalMachine may fail or produce an access-related error.
Temporarily Change the Policy for One Session
If you only need to run a script once and do not want a permanent change, use the Process scope:
This affects only the current PowerShell window. When you close it, the temporary policy is gone. This is useful for controlled troubleshooting, one-time setup scripts, or development tasks where you do not want to alter long-term system settings.
How To Run PowerShell With a Temporary Execution Policy
You can also start a new PowerShell session with a temporary execution policy from a command prompt or another shell. For Windows PowerShell, you can use:
For PowerShell 7 and later, the executable is usually pwsh.exe:
This does not permanently modify the saved policy. It applies to that session and its child processes. Think of it as borrowing a guest pass rather than changing the locks on the building.
How To Restore the Default Execution Policy
If you changed the policy and want to undo it, you can set the scope back to Undefined. For example:
To reset the local machine scope, open PowerShell as administrator and run:
You can then confirm the result with:
If no policy is defined in any scope, Windows applies its default behavior. On typical Windows client systems, that means scripts are restricted.
Fixing “Running Scripts Is Disabled on This System”
One of the most common reasons people search for how to change the PowerShell execution policy is this error:
To fix it for your user account, run:
Then try running your script again:
If the script was downloaded from the internet, Windows may mark it as coming from an external source. Under RemoteSigned, that script may still be blocked unless it is signed or unblocked.
Unblock a Downloaded Script
If you trust the file, you can unblock it with:
Only do this for scripts from trusted sources. Do not unblock random scripts from suspicious websites, email attachments, or “totally safe tools” shared by someone whose profile picture is a sports car and three fire emojis.
What To Do If the Policy Is Controlled by Group Policy
Sometimes you run Set-ExecutionPolicy, but PowerShell tells you the setting is overridden by a policy defined at a more specific scope. This often happens on work or school computers.
Check all scopes:
If MachinePolicy or UserPolicy is set, your organization is likely controlling PowerShell execution through Group Policy. In that case, changing CurrentUser or LocalMachine will not override it.
If this is a managed device, contact your IT administrator. Do not try to work around company policy unless you have permission. Besides being risky, it can violate internal security rules. No script is worth an awkward meeting with the compliance team.
PowerShell Execution Policy on Windows, macOS, and Linux
Execution policy matters primarily on Windows. In PowerShell 6 and later on non-Windows systems, the default policy is generally Unrestricted, and changing it is not supported in the same way as on Windows. If you use PowerShell on macOS or Linux, permissions, shell behavior, file ownership, and platform security features are usually more relevant than PowerShell execution policy.
For Windows users, however, the execution policy remains a common gatekeeper for scripts, especially in Windows PowerShell 5.1 and PowerShell 7 environments.
Best Practices for Changing PowerShell Execution Policy
Use CurrentUser Instead of LocalMachine When Possible
For personal development or learning, CurrentUser is usually enough. It avoids changing the experience for every user on the device and does not require administrator rights in many cases.
Prefer RemoteSigned for Everyday Use
RemoteSigned is a practical default for many users. It lets your own scripts run while still treating internet-downloaded scripts with suspicion. That is a healthy level of paranoia in computing.
Avoid Unrestricted as a Permanent Setting
Unrestricted may solve a problem quickly, but it weakens the safety net. If you use it for testing, consider switching back afterward.
Use Process Scope for One-Time Tasks
For temporary work, -Scope Process is your friend. It changes the policy only for the current session and leaves the system’s long-term configuration alone.
Read Scripts Before Running Them
Execution policy does not know whether a script is wise, foolish, useful, outdated, or secretly trying to rearrange your afternoon. Open scripts in a text editor before running them, especially if they came from the internet.
Sign Scripts in Professional Environments
For business and production environments, script signing is a smart practice. With AllSigned, organizations can require trusted digital signatures before scripts run. This supports better control, auditing, and trust.
Specific Examples
Example 1: Allow Your Own Scripts to Run
You created a script called backup-files.ps1, but PowerShell blocks it. Use:
Then run:
Example 2: Run One Setup Script Without Permanent Changes
You need to run a trusted setup script once. Use:
Close the PowerShell window when finished.
Example 3: Check Why Your Setting Is Not Working
You set RemoteSigned, but scripts are still blocked. Run:
If you see MachinePolicy or UserPolicy set to Restricted, a higher-priority policy is overriding your setting.
Common Mistakes To Avoid
Mistake 1: Using Unrestricted Without Understanding It
Many tutorials suggest Unrestricted because it makes errors disappear. Unfortunately, “the error disappeared” is not the same as “the system is configured wisely.” Use the least permissive policy that solves your problem.
Mistake 2: Forgetting the Scope
Running Set-ExecutionPolicy RemoteSigned without a scope may target LocalMachine, which can require administrator rights and affect all users. Be specific:
Mistake 3: Ignoring Downloaded File Blocking
A downloaded script may still fail under RemoteSigned. If you trust the file, use Unblock-File. If you do not trust it, do not run it. That is not paranoia; that is Tuesday in cybersecurity.
Mistake 4: Fighting Corporate Policy
If Group Policy controls execution policy, manual commands will not win. Ask IT for the approved method. In professional environments, policy exists for a reason, even when it interrupts your perfectly good plan to automate everything before lunch.
Real-World Experience: Lessons From Changing PowerShell Execution Policy
In real-world use, changing the PowerShell execution policy is rarely the hard part. The hard part is knowing how much change is appropriate. Many beginners discover execution policy while installing developer tools such as package managers, build systems, cloud command-line utilities, or framework setup scripts. The first instinct is to search the error, copy the shortest command, and move on. That works sometimes, but it can also create a messy configuration that nobody remembers later.
A practical experience-based approach is to start small. If you are working on your own machine, try RemoteSigned with CurrentUser. This solves many script-blocking problems without touching other accounts. It is especially useful for developers who create local scripts for build tasks, file cleanup, environment setup, or automation. The scripts you write yourself usually run without drama, while downloaded scripts still receive extra scrutiny.
Another lesson: temporary changes are underrated. When testing a one-time installer or lab script, -Scope Process is often cleaner than permanently changing the system. You open PowerShell, set the process policy, run the trusted script, and close the window. The machine does not carry that exception forever. This is the PowerShell equivalent of borrowing a tool and putting it back instead of leaving a circular saw in the hallway.
Administrators learn a different lesson: consistency matters. On business devices, execution policy should not be changed casually by each user. A team may decide to use AllSigned for production scripts, RemoteSigned for developer workstations, and Group Policy for enforcement. That creates predictability. When something breaks, admins can diagnose it faster because the policy is intentional rather than the result of twenty people following twenty different blog comments from 2012.
There is also a human side to execution policy. Error messages can make users feel blocked, especially when they are learning PowerShell for the first time. Explaining that execution policy is a safety feature, not a punishment, helps. It is there because scripts are powerful. A script can save hours, but a bad script can delete files, change settings, or expose data in seconds. Teaching users to read scripts, verify sources, and choose safer policies builds better habits than simply telling them to “run as admin and set unrestricted.”
One common troubleshooting pattern is checking the full policy list before changing anything. Running Get-ExecutionPolicy -List often reveals the real issue immediately. If CurrentUser is already RemoteSigned but MachinePolicy says Restricted, the problem is not your command. It is a higher-priority policy. That simple check can save a surprising amount of frustration.
The best experience-based advice is this: treat execution policy as a control knob, not an obstacle. Turn it only as far as needed. Use RemoteSigned for everyday scripting, Process for temporary exceptions, AllSigned for stricter environments, and Unrestricted only when you truly understand the consequences. PowerShell rewards careful users. It also has a long memory for careless commands.
Conclusion
Changing the PowerShell execution policy is a basic but important skill for anyone who runs scripts on Windows. The key is not just knowing the command, but knowing which policy and scope make sense for your situation. For most personal users, RemoteSigned at the CurrentUser scope is a practical and balanced choice. For temporary tasks, Process scope keeps changes short-lived. For organizations, Group Policy and script signing provide stronger consistency and control.
PowerShell is powerful, and execution policy is one of the guardrails that helps keep that power from turning into accidental chaos. Use it thoughtfully, check your scopes, avoid unnecessary risk, and your scripts will run without making your security posture look like it was assembled during a coffee shortage.
SEO Tags
Note: This article is based on current PowerShell documentation, Windows administration practices, and real-world troubleshooting patterns. Always follow your organization’s security policy before changing execution settings on a managed device.