Why does npm.ps1 say "running scripts is disabled" after installing OpenClaw?

Windows PowerShell defaults to the Restricted execution policy, which blocks all .ps1 script files including the npm.ps1 shim that npm installs for every global package. This is a Windows security default and is not caused by OpenClaw. Run Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass in your PowerShell window, then re-run the installer.

Do I need Git Bash to install OpenClaw on Windows?

No. Git Bash is not required. Regular PowerShell works once you relax the execution policy with Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass. Git Bash is a common workaround because it uses a Unix shell that ignores the Windows policy, but it is not necessary.

What is the safest way to fix the PowerShell execution policy for OpenClaw?

The safest fix is Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass. The -Scope Process flag limits the change to your current terminal session only — it resets when you close the window and does not alter any machine-wide or user-wide setting. For a persistent but still scoped change, use -Scope CurrentUser -ExecutionPolicy RemoteSigned.

Can I use WSL instead of fixing the PowerShell execution policy?

Yes. Installing OpenClaw inside WSL (Windows Subsystem for Linux) avoids the PowerShell execution policy entirely. WSL gives you a full Linux shell where you can use the standard curl | bash installer. See the OpenClaw WSL guide at openclawlaunch.com/guides/openclaw-wsl for a full walkthrough.

← Home

Troubleshooting

Fix OpenClaw Windows Install Error: "Running Scripts Is Disabled" (PowerShell Execution Policy)

Ran iwr -useb https://openclaw.ai/install.ps1 | iex or an npm command and hit a script-blocked error? This is a Windows PowerShell ExecutionPolicy restriction, not an OpenClaw bug. The fix takes under a minute.

What the Error Looks Like

After running the OpenClaw installer or the first npm command following installation, PowerShell prints something like:

npm.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.

You may see this immediately after pasting the one-liner installer (iwr -useb https://openclaw.ai/install.ps1 | iex), or only when you first run npm install or openclaw afterward. Both cases have the same root cause.

Why Does This Happen?

Windows PowerShell ships with its execution policy set to Restricted by default. In this mode, PowerShell refuses to run any script file — including the .ps1 shims that npm places in your PATH for every global package it installs.

When you install OpenClaw (or Node.js itself), npm creates a file called npm.ps1 alongside the npm.cmd wrapper. PowerShell finds the .ps1 shim first and immediately blocks it. The .cmd file would work fine, but PowerShell does not fall through to it on its own.

This is entirely a Windows security default — OpenClaw's installer is not doing anything unusual. The same error appears for any globally-installed npm package on a fresh Windows machine.

Fix 1: Bypass for the Current Session Only (Recommended)

The safest approach is to relax the policy only for the terminal window you are currently using. The setting disappears when you close that window:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

After running that command, re-run the OpenClaw installer or the npm command that was blocked. Everything should proceed normally.

You only need to repeat this once per new PowerShell window if you prefer not to make a permanent change. The -Scope Process flag ensures no system-wide or user-wide policy is altered.

Fix 2: Persistent Change for Your User Account

If you work with npm or scripts regularly and do not want to repeat the session fix each time, set the policy persistently for your Windows user account:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

RemoteSigned requires that scripts downloaded from the internet be digitally signed, but allows locally-created scripts to run freely. This is the standard developer setting Microsoft recommends — it is more selective than Bypass while still unblocking npm shims and the OpenClaw installer.

You may need to confirm the change by typing Y when prompted. The setting persists across reboots and applies only to your account, not other users on the machine.

Fix 3: Run PowerShell as Administrator

In some corporate or managed environments, the user-level policy is locked by Group Policy. Opening PowerShell as Administrator can sometimes bypass that restriction:

Right-click the Start menu and choose Windows PowerShell (Admin) or Terminal (Admin).
Run Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass in the admin window.
Re-run the OpenClaw installer from the same elevated window.

If Group Policy is enforcing a machine-wide restriction, you will need to speak with your IT administrator or use the WSL alternative below.

Do I Need Git Bash?

No. Git Bash is not required to install or run OpenClaw on Windows. Regular PowerShell works perfectly once the execution policy is relaxed using any of the fixes above.

Git Bash is a common workaround people reach for because it uses a Unix shell that ignores Windows execution policy entirely. But you do not have to install Git just to fix this error. If you already have Git Bash installed, you can use it — the installer runs fine there too.

Alternative: Use WSL (Windows Subsystem for Linux)

If you prefer a Linux-native environment or run into further Windows-specific friction, installing OpenClaw inside WSL is a clean alternative. WSL gives you a full Ubuntu shell where execution policy is not a concept and the standard Linux install path applies:

curl -fsSL https://openclaw.ai/install.sh | bash

See the OpenClaw WSL guide for the full setup walkthrough.

Security Note: Avoid Machine-Wide Unrestricted

You may find advice online suggesting this command:

Set-ExecutionPolicy -ExecutionPolicy Unrestricted

Avoid it. Without a -Scope flag it defaults to LocalMachine, affecting every user and every PowerShell session on the computer. Unrestricted also runs downloaded scripts after only a warning prompt — a weaker guard than RemoteSigned. Prefer scoping the change to Process (temporary) or CurrentUser(persistent but isolated to your account).