PowerShell 运行 OpenClaw 安装脚本报错 running scripts is disabled on this system 的解决方案

1. 问题描述

按照 OpenClaw 官方文档，在 Windows 上用 PowerShell 执行一键安装脚本时，很多人会立刻被这条报错拦在第一步：

PS C:\Users\admin> iwr -useb https://openclaw.ai/install.ps1 | iex
install.ps1 : File C:\Users\admin\install.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

有些人会看到稍微不同但本质相同的变体：

.\install.ps1 : 无法加载文件 C:\Users\admin\install.ps1，因为在此系统上禁止运行脚本。
有关详细信息，请参阅"https:/go.microsoft.com/fwlink/?LinkID=135170"中的 about_Execution_Policies。

这个问题在全新安装的 Windows 系统（企业镀膜机、新买的电脑）、公司统一配置的办公电脑、从未主动修改过 PowerShell 安全设置的个人电脑这几种场景下几乎是必然会遇到的第一道门槛。很多人第一反应是以为下载的脚本本身损坏了，或者怀疑是网络问题导致文件没下全，反复重新执行那条 iwr 命令依然无效——但实际上这个报错和脚本内容、网络状况完全无关，它是 Windows PowerShell 的一项内置安全机制，专门用来防止用户"不小心"运行来源不明的脚本，属于系统层面主动拦截，而不是程序本身出了故障。

2. 原因分析

PowerShell 从设计之初就内置了一套叫做**执行策略（Execution Policy）**的安全机制，用来控制"在这台机器上，允许以什么条件运行 .ps1 脚本文件"。这个机制的存在是为了防止恶意脚本（比如从邮件附件、网页下载的脚本）在用户毫无察觉的情况下被静默执行。

Windows 系统给不同类型的用户账户/安装场景设置了不同的默认执行策略，最常见的默认值是 Restricted（完全禁止运行任何脚本文件，只能执行单条命令）。当你运行安装脚本时，PowerShell 会先检查当前生效的执行策略，如果策略判定"不允许运行"，就直接拒绝加载这个脚本文件，连脚本的第一行代码都不会执行。

PowerShell 的执行策略分为几个常见等级，从最严格到最宽松：

策略等级	含义
Restricted（默认，多数场景）	完全不允许运行任何 .ps1 脚本文件
AllSigned	只允许运行经过受信任发布者数字签名的脚本
RemoteSigned	本地编写的脚本可以直接运行；从网络下载的脚本必须有数字签名
Unrestricted	允许运行所有脚本，但从网络下载的脚本运行前会有一次确认提示
Bypass	完全不做任何检查、不提示，风险最高

而且这个策略是分层生效的——存在 MachinePolicy（组策略强制指定，优先级最高，普通用户无法覆盖）、UserPolicy、Process（仅当前这个 PowerShell 窗口生效）、CurrentUser、LocalMachine 五个作用域，实际生效的是这几层里"优先级最高且非 Undefined"的那一层。用一张流程图梳理判定逻辑：

执行 .ps1 脚本文件
        ↓
PowerShell 依次检查五个作用域的执行策略（按优先级从高到低）
   MachinePolicy → UserPolicy → Process → CurrentUser → LocalMachine
        ↓
   找到第一个非 Undefined 的策略值
        ↓
   该策略是否允许运行这类脚本？
        ├─ 允许（RemoteSigned及以上，或本地脚本满足条件）→ 正常执行
        └─ 不允许（Restricted）→ 抛出 UnauthorizedAccess，拒绝加载

3. 解决方案

方案一：为当前用户放宽执行策略为 RemoteSigned（最推荐，最安全的日常方案）

在 PowerShell 里执行（不需要管理员权限，只影响当前用户账户）：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

执行后会弹出一个确认提示，输入 Y 并回车确认。这个设置的含义是：你自己写的、或者从本地磁盘直接运行的脚本可以自由执行；但从互联网下载下来的脚本，必须带有可信任的数字签名才允许运行——这是官方长期推荐的一个"既不完全裸奔、又不至于处处受限"的平衡设置。

设置完成后重新运行安装脚本：

iwr -useb https://openclaw.ai/install.ps1 | iex

方案二：仅对当前这一次会话临时放宽策略（最保守，用完即恢复默认）

如果你不想改动系统级或用户级的长期配置，只是想装这一次 OpenClaw，可以只对当前这一个 PowerShell 窗口临时放宽策略，窗口一关闭，设置自动失效，不留任何后续影响：

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process -Force
iwr -useb https://openclaw.ai/install.ps1 | iex

-Scope Process 决定了这个改动只在当前这一个进程（窗口）内生效，关掉窗口重新打开一个新的，策略又会恢复回之前的默认值，是排查/临时使用时最"干净"的方式。

方案三：绕开执行策略检查，用 Bypass 参数直接调用脚本文件

如果你已经把安装脚本下载到本地了（而不是用 iwr | iex 这种直接管道执行的方式），可以在调用脚本的时候单独加一个 -ExecutionPolicy Bypass 参数，只对这一次调用生效，不改任何全局配置：

# 先把脚本下载到本地
Invoke-WebRequest -Uri "https://openclaw.ai/install.ps1" -OutFile "$env:TEMP\install.ps1"

# 用 Bypass 参数单独调用这一个脚本文件，不影响系统整体策略
powershell -ExecutionPolicy Bypass -File "$env:TEMP\install.ps1"

这种方式的好处是先把脚本落地到本地，你可以在执行前先打开看一眼脚本内容确认安全，再决定是否运行，比直接管道执行（iwr | iex）多了一层可审查性。

⚠️ 风险提示：无论用哪种方式绕开执行策略限制，都建议先看一眼脚本内容再执行，尤其是像 iwr -useb <url> | iex 这种"下载后立即执行、不落地保存、你根本看不到内容"的写法，本质上是完全信任了这个 URL 背后的内容。只从你确认可信的官方域名（如 openclaw.ai）下载脚本，不要对来源不明的链接使用这种一键执行方式。

方案四：公司/企业电脑遇到组策略强制锁定，无法自行修改时的处理

如果执行 Set-ExecutionPolicy 后收到类似下面的报错：

Set-ExecutionPolicy : 无法在 Windows PowerShell 1 范围"MachinePolicy"中执行设置操作
或获取操作，因为该范围当前由位于"..."的策略锁定。

说明你所在的公司通过组策略（Group Policy）在 MachinePolicy 这一层强制锁定了执行策略，优先级高于你能设置的任何用户级配置，普通用户是无法绕过的。这种情况下正确的处理方式是联系公司 IT/运维部门，说明你需要运行经过审查的开发工具安装脚本，申请对应权限或申请在你的账户上开一个例外，而不是尝试各种"绕过"的野路子——企业环境这样限制往往是出于合规和安全审计的要求。

方案五：改用非 PowerShell 脚本方式安装，完全规避执行策略问题

如果你确实不想触碰执行策略这个话题（比如受限环境、或者单纯不想动系统安全设置），可以选择官方文档提到的另一条路径——通过 WSL2 用 Linux 风格的 shell 脚本安装，Linux 环境的 bash 脚本执行机制和 Windows PowerShell 的执行策略是完全独立的两套体系，不会受这个问题影响：

# 先在 PowerShell（管理员）中安装 WSL2
wsl --install

重启后进入 WSL2 环境，用 Linux 平台的标准安装方式：

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

这种方式实质上是换了一套完全不同的执行环境，从根源上避开了 Windows PowerShell 的这层安全限制，对于经常需要执行各类开发工具安装脚本的开发者来说，长期来看也更省心。

4. 各方案对比总结

方案	适用场景	推荐指数
CurrentUser 设为 RemoteSigned	个人电脑，长期使用，官方推荐的平衡方案	⭐⭐⭐⭐⭐
Process 范围临时 Bypass	只想装这一次，不想留下长期配置改动	⭐⭐⭐⭐
下载到本地后用 -ExecutionPolicy Bypass 调用	想先审查脚本内容再执行，安全意识更高	⭐⭐⭐⭐
联系IT申请例外	公司电脑被组策略强制锁定	⭐⭐⭐⭐
改用 WSL2 安装	完全规避 Windows 执行策略话题	⭐⭐⭐

5. 常见问题 FAQ

5.1 修改执行策略会不会让我的电脑变得不安全？

不会带来显著风险，只要按照方案一使用 RemoteSigned（而不是 Unrestricted 或 Bypass 这种最宽松等级）。RemoteSigned 的设计初衷就是"本地脚本可以自由跑，网络下载的脚本必须有签名"，这是微软官方长期推荐用于开发者日常使用的等级，并不等同于彻底关闭安全防护。真正需要警惕的是把策略设成 Bypass 并作为长期默认配置，那样才是把这层防护完全关闭了。

5.2 为什么公司电脑和自己家里的电脑，默认执行策略不一样？

Windows 系统默认的执行策略其实一直是 Restricted，但很多个人电脑用户之前可能已经因为其他原因（比如装过其他开发工具）改过这个设置，所以感觉不到限制。企业电脑往往会通过组策略统一管理，出于安全合规要求刻意保持严格设置，且这个设置对普通用户账户不可覆盖，这属于正常且合理的企业安全策略，不是软件或系统故障。

5.3 用 irm | iex 而不是 iwr | iex，会不会绕开这个限制？

不会。irm（Invoke-RestMethod）和 iwr（Invoke-WebRequest）只是两种不同的网络请求方式，iex（Invoke-Expression）才是真正负责执行脚本内容的那部分。执行策略检查的是"是否允许执行脚本内容"，与你用什么方式把脚本内容下载下来完全无关，换成 irm 组合同样会遇到一样的执行策略报错（如果确实触发了脚本文件加载检查）。

5.4 Windows Server（服务器版）上安装时报的执行策略错误，处理方式一样吗？

原理完全一致，Windows Server 的默认执行策略同样是 Restricted，处理方式和普通 Windows 桌面版没有区别，用方案一或方案二都能正常解决。唯一需要多留意的是：服务器环境下更应该谨慎选择 RemoteSigned 而不是更宽松的等级，毕竟服务器上跑的脚本一旦出问题影响范围可能更大，安全意识要更谨慎一些。

5.5 团队协作中，如何避免每个新同事第一次装 OpenClaw 都被这个问题卡住？

建议在项目 README 的 Windows 安装章节里，直接把方案一的那一行命令和一句简短解释放在安装步骤最前面，作为"Windows 用户请先执行这一步"的强制性前置说明，而不是等大家各自撞上报错后再各自去搜索解决方案。这样能把这个几乎人人都会遇到的第一道坎，一次性提前拦截掉。

5.6 CI/CD 流水线（比如自建的 Windows Runner）上跑安装脚本，也会遇到这个问题吗？

会。CI 用的 Windows 虚拟机/容器同样有默认的执行策略限制，需要在流水线脚本里显式指定绕过方式，而不能假设"CI 环境应该没有限制"：

# 在 CI 脚本步骤里显式指定
powershell -ExecutionPolicy Bypass -Command "iwr -useb https://openclaw.ai/install.ps1 | iex"

由于 CI 环境每次运行都是全新的虚拟机/容器实例，用 -ExecutionPolicy Bypass 这种"仅本次调用生效"的方式反而更合适，不需要也不应该去修改这类临时环境的持久化配置。

5.7 排查清单速查表

□ 1. 用 Get-ExecutionPolicy -List 查看当前所有作用域的策略值，定位哪一层在拦截
□ 2. 判断这台电脑是个人电脑还是受组策略管控的企业电脑
□ 3. 个人电脑：优先用 Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
□ 4. 只想临时装这一次：用 -Scope Process 方式，关窗口自动恢复
□ 5. 企业电脑被 MachinePolicy 锁定：联系 IT 部门申请例外，不要强行绕过
□ 6. 对来源不明的一键安装脚本，优先下载到本地审查内容后再执行
□ 7. 修改完成后，重新执行原来的安装命令验证是否能正常继续
□ 8. 长期反复遇到类似问题，考虑迁移到 WSL2 环境规避该系统层限制

6. 总结

cannot be loaded because running scripts is disabled on this system 不是安装脚本坏了，也不是网络问题，而是 Windows PowerShell 内置的执行策略安全机制在主动拦截。核心处理思路可以浓缩成三句话：

1. 这是安全特性，不是故障——理解它的设计初衷（防止误运行恶意脚本），能帮你更从容地判断该用哪种放宽方式，而不是盲目地"能跑就行"；
2. RemoteSigned 是日常使用的最佳平衡点——既不是完全裸奔的 Bypass，也不会处处受限，是官方长期推荐的开发者常用等级；
3. 企业电脑遇到组策略锁定要走正规流程——联系 IT 申请例外，而不是想办法"越狱"绕过公司的安全合规设置。

最佳实践建议：养成"对不熟悉来源的一键安装脚本，先下载到本地看一眼内容再执行"的习惯，这既能规避这类执行策略报错带来的困惑，也能顺手多一层安全审查，一举两得。