最近在使用 OpenAI Codex（Windows Sandbox 模式）时，执行任何命令都会立即失败，日志中出现类似错误：

windows sandbox: CreateProcessAsUserW failed: 5 (拒绝访问。)

cwd=D:\...
cmd=C:\Users\<User>\AppData\Local\Microsoft\WindowsApps\pwsh.exe ...

一开始很容易怀疑是：

• Windows Sandbox 配置错误
• UAC 权限问题
• 杀毒软件拦截
• Codex Bug

实际上，这些都不是根本原因。

最终定位到的问题是 PowerShell 7 的安装方式。

---

问题现象

Codex 在执行任何命令时都会失败，例如：

Get-Date

甚至最简单的：

Get-ChildItem

都会直接报错：

CreateProcessAsUserW failed: 5 (Access Denied)

注意，这里的错误发生在 PowerShell 启动之前。

也就是说：

PowerShell 根本没有运行起来。

---

Codex Windows Sandbox 的工作方式

理解这个问题，需要先了解 Codex Windows Sandbox 的运行机制。

为了避免 AI 直接获得当前用户的完整权限，Codex 不会直接执行：

Codex.exe
    │
    └── pwsh.exe

而是大致采用如下流程：

Codex.exe
    │
    ├── 创建受限 Token（Restricted Token）
    │
    ├── 创建隔离环境（Sandbox）
    │
    └── CreateProcessAsUserW(...)
             │
             └── 启动 PowerShell

这里最关键的是：

Codex 使用的是 Windows 的受限访问令牌（Restricted Token）启动 PowerShell。

这样做的目的是：

• 限制 AI 能访问的目录；
• 防止修改系统文件；
• 防止访问用户全部权限。

因此，PowerShell 并不是在当前用户的完整登录环境中启动，而是在一个受限的 Sandbox 中运行。

---

CreateProcessAsUserW 是什么？

日志中的：

CreateProcessAsUserW failed

实际上是 Windows API：

CreateProcessAsUserW(...)

它的作用是：

使用指定用户 Token 创建新的进程。

Codex 正是通过它启动 Sandbox 中的 PowerShell。

错误码：

5 = ERROR_ACCESS_DENIED

说明：

Windows 拒绝了这次进程创建。

这里失败的位置不是 PowerShell，而是在 Windows 创建 PowerShell 进程的阶段。

---

为什么 PowerShell 会影响 Sandbox？

继续查看日志：

cmd=C:\Users\<User>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

这个路径非常关键。

很多人认为：

pwsh.exe

就是 PowerShell。

实际上：

C:\Users\<User>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

通常只是 App Execution Alias（应用执行别名）。

真正的 PowerShell 并不在这里。

---

App Execution Alias 是什么？

如果通过：

• winget
• Microsoft Store

安装 PowerShell 7，那么系统通常不会把真正的 pwsh.exe 放入 PATH，而是放入一个：

WindowsApps

目录。

执行流程实际上类似于：

pwsh.exe（Alias）

↓

Windows App Execution Alias

↓

MSIX Package

↓

真正的 PowerShell

也就是说：

Windows 需要先完成 MSIX 应用激活（Package Activation），然后才能真正启动 PowerShell。

---

为什么 Sandbox 会失败？

问题就在这里。

Codex Sandbox 启动 PowerShell 时：

• 使用的是 Restricted Token；
• 不具备普通用户完整登录上下文；
• 不具备普通 MSIX 应用启动所需的环境。

因此：

CreateProcessAsUserW

↓

WindowsApps Alias

↓

MSIX Activation

↓

Access Denied

于是出现：

CreateProcessAsUserW failed: 5

并不是 PowerShell 本身没有权限，而是 MSIX 包激活机制与 Codex 的受限 Sandbox 不兼容。

---

如何确认是不是这个问题？

执行：

where.exe pwsh

如果得到：

C:\Users\<User>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

基本可以确认：

当前使用的是 MSIX（Microsoft Store / winget）版本。

如果得到：

C:\Program Files\PowerShell\7\pwsh.exe

则说明使用的是传统安装版。

---

为什么 MSI 安装没有问题？

从 GitHub Releases 下载 MSI 安装包后，PowerShell 会直接安装到：

C:\Program Files\PowerShell\7\

启动过程变成：

CreateProcessAsUserW

↓

C:\Program Files\PowerShell\7\pwsh.exe

↓

PowerShell

整个过程不需要：

• WindowsApps Alias
• MSIX Activation
• Package Identity
• AppX Broker

因此，Sandbox 可以正常创建 PowerShell 进程。

---

正确的安装方式

建议不要使用：

• Microsoft Store
• winget 默认安装（MSIX）

而是直接从 GitHub Releases 下载官方 MSI 安装包。

安装完成后，确认：

where.exe pwsh

输出类似：

C:\Program Files\PowerShell\7\pwsh.exe

而不是：

C:\Users\<User>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

---

为什么微软文档容易让人踩坑？

微软 PowerShell 官方安装文档中，winget install Microsoft.PowerShell 是非常推荐的安装方式，对于普通用户完全没有问题。

但是需要注意：

winget 默认获取的是 Microsoft Store（MSIX）版本时，其启动方式依赖 WindowsApps Alias。

对于日常终端使用没有任何影响。

但是对于：

• Codex Windows Sandbox
• 使用 CreateProcessAsUserW
• 使用 Restricted Token
• 使用隔离用户启动进程

这类程序，就可能出现兼容性问题。

因此，对于开发环境，尤其需要与各种 IDE、CLI、Sandbox、CI 工具配合时，更推荐使用 GitHub Releases 提供的 MSI 安装包。

---

总结

整个问题可以概括为下面这条调用链：

Codex Sandbox
        │
        ▼
CreateProcessAsUserW
        │
        ▼
WindowsApps\pwsh.exe（App Execution Alias）
        │
        ▼
MSIX Package Activation
        │
        ▼
Access Denied

而改为 MSI 安装后，则变为：

Codex Sandbox
        │
        ▼
CreateProcessAsUserW
        │
        ▼
C:\Program Files\PowerShell\7\pwsh.exe
        │
        ▼
PowerShell 正常启动

因此，本次问题的根本原因并不是 Codex 本身，也不是 PowerShell 本身，而是 MSIX 应用启动机制与 Codex Windows Sandbox 的受限进程模型之间的兼容性问题。

对于需要使用 Codex、Windows Sandbox 或其他基于受限 Token 创建进程的开发工具，建议优先安装 GitHub Releases 提供的 MSI 版本 PowerShell，避免使用依赖 WindowsApps Alias 的 MSIX 安装方式，从源头规避这类问题。