Windows自动更新后Codex沙箱报错问题排查与解决方法

分享一次 Codex Windows 桌面端自动更新后，sandbox 报错的完整排查过程。先说结论：这个问题不像常见的项目目录权限或 node_modules 路径过深；更值得怀疑的是，自动更新后 WindowsApps 应用包里的 appresources 可执行文件被标记为 Encrypted / Application Protected 状态，导致沙箱上下文无法正常执行或加载。

问题背景

Codex Windows 桌面端左上角出现蓝色更新图标后，点击执行了自动更新。更新完成后，沙箱相关操作便开始间歇性报错，典型报错如下：

codex-windows-sandbox-setup.exe
找不到指定的模块。

后续排查中还出现了另一个关键错误：

程序“rg.exe”无法运行: 拒绝访问。

环境信息整理如下：

OS: Windows 11, 26100 系列
Shell: Windows PowerShell 5.1
Codex app package path:
C:Program FilesWindowsAppsOpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0

Codex runtime cache version:
26.622.11653

排查结论

问题并非“沙箱完全坏掉”。分步测试结果很有意思：

• 最小 PowerShell 启动：成功
• 工作区文件写入：成功
• apply_patch 编辑：间歇性失败
• 中文路径写入：成功
• 读取 .codex.sandbox-bin：成功
• 读取 .cachecodex-runtimes：成功
• 读取 WindowsApps 中的 exe 属性：成功
• 执行 WindowsApps...appresourcesrg.exe：失败，拒绝访问

也就是说，普通沙箱启动和工作区读写大多正常。真正异常集中在一个位置：

C:Program FilesWindowsAppsOpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0appresources

这个目录里的可执行文件可以找到、可以读取属性，但在当前上下文中无法执行。

关键证据 1：PATH 仍指向旧 app 包

当前 Codex 进程的 PATH 中包含：

C:Program FilesWindowsAppsOpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0appresources

但重新生成后的 runtime cache 显示：

bundleVersion = 26.622.11653

自动更新后出现了一个可疑状态：

runtime cache 已经是 26.622.11653
但当前 app 进程和 PATH 仍指向 26.616.9593.0 的 WindowsApps 包

不能直接断定版本号必须一致（app package version 和 runtime bundle version 可能采用不同编号系统），但从故障现象看，这种“更新后路径仍指向旧包”的状态确实值得警惕。

关键证据 2：同目录 rg.exe 不能执行

codex-windows-sandbox-setup.exe 是沙箱 setup 程序，直接运行可能修改沙箱账户或权限，谨慎起见未贸然操作。为降低风险，用同目录下的 rg.exe 进行了对照测试：

Get-Command codex-windows-sandbox-setup.exe,rg.exe

两者均解析到：

C:Program FilesWindowsAppsOpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0appresources

随后执行：

rg.exe --version

结果失败：

程序“rg.exe”无法运行: 拒绝访问。
CategoryInfo: ResourceUna vailable
FullyQualifiedErrorId: NativeCommandFailed

同一个 appresources 目录里的普通工具也无法在当前上下文中运行。

关键证据 3：文件是 Encrypted / Application Protected

检查失败文件的属性：

Get-Item "C:Program FilesWindowsAppsOpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0appresourcesrg.exe"
Get-Item "C:Program FilesWindowsAppsOpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0appresourcescodex-windows-sandbox-setup.exe"

两者均显示：

Attributes: Archive, Encrypted

继续使用：

cipher /c "C:Program FilesWindowsAppsOpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0appresourcesrg.exe"
cipher /c "C:Program FilesWindowsAppsOpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0appresourcescodex-windows-sandbox-setup.exe"

结果均为：

E rg.exe
  Compatibility Level:
    Application Protected

E codex-windows-sandbox-setup.exe
  Compatibility Level:
    Application Protected

这说明这些文件属于 WindowsApps 应用包中受保护加密的文件。当前上下文可以定位文件，但执行或加载时可能无法通过 Windows 应用保护机制。

关键证据 4：并非所有 exe 都不能运行

为排除“沙箱环境禁止所有外部 exe”的可能性，验证了 runtime cache 中的 Git：

C:Userslenovo.cachecodex-runtimescodex-primary-runtimedependenciesnativegitcmdgit.exe --version

执行成功：

git version 2.53.0.windows.3

这说明问题并非泛化 exe 执行失败，而是更集中于 WindowsApps app package 的 appresources 目录。

node_modules 路径过深是不是原因？

排查过程中确实遇到过 node_modules 深层路径问题：

Copy-Item : Could not find a part of the path ...
...node_modules.pnpm@napi-rs+canvas-win32-x64-msvc...

这是备份 runtime cache 时触发的路径长度问题。使用 robocopy 后复制成功，FAILED = 0。

但这并非核心沙箱报错的原因。理由如下：

1. 主要失败点 rg.exe 位于 WindowsApps 的 appresources，路径长度远不足 260 字符；
2. codex-windows-sandbox-setup.exe 也在同一短路径目录；
3. 两者共同的异常是 Encrypted / Application Protected，而非路径过深。

因此可以区分：

node_modules 路径过深：备份过程中的次要问题
WindowsApps resources exe 拒绝执行：本次沙箱报错的主要问题

为什么 apply_patch 也会报错？

排查后期，apply_patch 也触发了一次沙箱 helper 报错：

windows sandbox failed: orchestrator_helper_launch_canceled:
ShellExecuteExW failed to launch setup helper: 1223

此错误与普通 Set-Content 写文件不同。apply_patch 并非简单在当前 PowerShell 中写文件，而是调用 Codex 自己的文件编辑通道，在需要时启动 Windows sandbox setup/helper 相关组件。当前机器上可疑的失败点正是：

C:Program FilesWindowsAppsOpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0appresourcescodex-windows-sandbox-setup.exe

因此，apply_patch 报错可理解为：

普通 shell 写入仍可成功
但 Codex 专用编辑通道需要启动 sandbox setup/helper
→ helper 位于 WindowsApps appresources
→ 该目录中的 exe 是 Encrypted / Application Protected
→ 当前上下文无法稳定启动 helper
→ apply_patch 失败

这解释了为何后来使用普通 PowerShell：

Set-Content -LiteralPath .outputsxxx.md -Encoding UTF8

可以成功写入 Markdown，而 apply_patch 却失败。

可能触发类似报错的操作

以下操作更容易触发同类问题，因为它们可能要求 Codex 调用 sandbox setup/helper、命令 runner 或 WindowsApps appresources 下的可执行文件。

需要区分两类错误：

路径过深 / node_modules：主要影响复制、备份、Copy-Item
WindowsApps Application Protected：主要影响执行 appresources 里的 exe

本次 apply_patch 更符合第二类：它可能间接触发了 WindowsApps 中的 sandbox setup helper。

尝试过的修复

1. 清理旧 runner 残留

.codex.sandbox-bin 中存在多个旧版本 runner。旧版本移至 quarantine，仅保留：

codex.exe
codex-command-runner-0.142.0.exe

结果：普通沙箱写入仍成功，但 WindowsApps resources 执行问题未消失。

2. 隔离并重建 runtime cache

备份后隔离：

C:Userslenovo.cachecodex-runtimes

重启 Codex 后，该目录可重新生成。

结果：runtime cache 重建成功，但 rg.exe --version 仍然返回 拒绝访问。

3. Windows App Repair

执行 Codex app 的 Repair 后再次测试。

结果：未修复。

4. Windows App Reset

执行 Codex app 的 Reset 后再次测试。

结果：仍未修复。说明 Reset 主要影响应用数据和缓存，并未重新部署 WindowsApps app 包本体。

当前推断

根据现有证据，更可能的错误链路是：

Codex 需要运行 codex-windows-sandbox-setup.exe
→ PATH 解析到 WindowsAppsOpenAI.Codex_26.616...appresources
→ 该 exe 是 Encrypted / Application Protected
→ 当前沙箱启动上下文无法正常执行或加载
→ 报 “找不到指定的模块” 或 “拒绝访问”

这更像是 Codex Windows 自动更新后，本地 app package 部署或应用保护状态异常，而非项目目录权限、普通 sandbox 配置、runtime cache 或 node_modules 路径过长导致的问题。

建议解决方案

按风险从低到高排列：

1. 完全退出 Codex，包括后台和托盘进程，然后重新打开。
2. 备份关键目录：

C:Userslenovo.codex
C:Userslenovo.cachecodex-runtimes
C:UserslenovoDocumentsCodex

3. 尝试 Windows 设置中的 Repair。
4. 如不担心登录状态和本地缓存丢失，可尝试 Reset。
5. 若 Repair 和 Reset 均无效，建议卸载 Codex，并从官方渠道重新下载安装。

不建议直接手动修改 C:Program FilesWindowsApps 下的文件权限、加密属性或 exe 文件。该目录由 Windows 应用包机制管理，强行修改可能破坏应用签名、包注册及后续更新。