自 2026年10月7日起，在 Windows 上使用 Codex 应用并开启 elevated 沙箱的用户发现，所有命令在启动前就失败了。一个无害的 Get-Location 也会返回 Failed to create unified exec process: helper_unknown_error: setup refresh had errors，Node REPL 也随之报错 trusted Node process exited unexpectedly。Issue #51601 三天内评论超过 119 条。
好消息是：修复已经发布。但这条报错很笼统，不止一种原因会触发它。本文教你在日志里找到真正的原因，以及每种原因对应的解决办法。
Codex 的 "setup refresh had errors" 是什么意思？
意思是 Windows 沙箱辅助程序（codex-windows-sandbox-setup.exe）在运行你的命令之前准备权限时失败了，于是 Codex 拒绝执行。报错本身不会告诉你哪一步失败，沙箱日志会。
每条命令运行前，Codex 都会调用这个辅助程序，检查代理要用到的文件夹的权限（ACL）。只要任何一个必需步骤失败，命令就不会启动。所以无论你执行的是 git status 还是构建，症状都一样，耗时都是 0 ms。
在哪里看到真正的原因？
在 %USERPROFILE%\.codex\.sandbox\sandbox.<日期>.log 文件里。最近一次失败也会汇总在 %USERPROFILE%\.codex\.sandbox\setup_error.json。在 PowerShell 中，下面的命令会列出最近的相关行：
Select-String -Path "$env:USERPROFILE\.codex\.sandbox\sandbox.*.log" -Pattern "os error|failed" | Select-Object -Last 20如果你用的是 CLI，codex doctor --summary 也会在沙箱配置记录到失败时给出提示。
有一行容易误导：failed to grant non-inheriting read-attributes ACE on user profile ... (os error 32); continuing setup。它以 continuing setup 结尾，说明不是致命错误。请看它后面的那一行。
日志里的哪一行对应哪种原因？
| 日志行 | 原因 | 解决办法 |
|---|---|---|
runtime read/execute validation failed ... cua_node\...\node_repl.exe ... (os error 32) | 应用 26.1002.x（内置 CLI 0.162.0-alpha.2）附带的辅助程序出现回归 | 把应用更新到 26.1007.21434 或更新版本 |
setup refresh failed to launch helper Access denied (os error 5) | 辅助程序无法从安装包的 WindowsApps 文件夹启动 | 设置 CODEX_CLI_PATH 变量，指向另一份 codex.exe |
| 只在某一个项目文件夹失败，其他文件夹正常 | 工作区状态卡在那个路径上 | 通过目录联接（mklink /J）打开同一个仓库 |
10 月的这次故障属于第一行，本文接下来解决的就是它。
为什么 10月7日以来会出现 os error 32？
因为新的辅助程序开始校验 cua_node 运行时中每个文件的权限，校验时以 MAXIMUM_ALLOWED 访问权限打开文件，而 Windows 会拒绝对正在使用的文件发出这种请求。os error 32 就是 ERROR_SHARING_VIOLATION。
卡死一切的细节是：占用这些文件的正是 Codex 自己。应用会从这个文件夹持续运行 node_repl.exe 和 codex-computer-use-swift.exe。Issue 中的用户反馈，结束这些进程只会让失败转移到下一个被占用的文件（一个 DLL），而且应用会在不到一秒内重新拉起进程。重启应用或 Windows 都无济于事。
OpenAI 在 PR #51822 中修复了这个问题，该 PR 于 2026年10月7日合并：MAXIMUM_ALLOWED 现在只用于文件夹，文件只在确实需要修改 ACL 时才以 READ_CONTROL | WRITE_DAC 打开。
如何在 Codex 应用中解决 os error 32？
把应用更新到 26.1007.21434（build 13901）或更新版本。多位用户在 2026年10月9日和10日于 issue 中确认，在保持 elevated 沙箱不变的情况下，命令、Node REPL 和浏览器控制都恢复正常，无需额外步骤。
- 在 About Codex 中查看版本。如果显示 26.1002.x，说明你在受影响的版本上。
- 通过 Microsoft Store（库，然后获取更新）或在终端中更新：
winget upgrade --id 9PLM9XGG6VKS -s msstore - 完全退出应用，再重新打开。
- 执行一条简单命令，确认日志中不再出现
runtime read/execute validation failed。
暂时无法更新怎么办？
在 %USERPROFILE%\.codex\config.toml 中临时把沙箱切换为 unelevated 模式：
[windows]
sandbox = "unelevated"根据仓库中的配置 schema，这个键可接受的值是 elevated、unelevated 和 mxc。关闭所有应用实例（包括任务管理器里隐藏的实例）后重新打开。Issue 中做了这项切换的用户反馈，命令和文件编辑恢复可用，部分情况下只是部分恢复。
这只是权宜之计，不是修复。unelevated 模式使用受限令牌，根据代码自带的文档，它支持的文件系统策略比 elevated 少。更新之后请尽快切回 elevated。
通过 npm 安装的 Codex CLI 也会受影响吗？
有可能。有用户反馈，在同一台机器装有桌面应用的情况下，全局安装的 @openai/codex@0.161.0 也出现了同样的 os error 32。我们在 2026年10月10日核对了代码：PR #51822 的修复已在 main、0.162.0-alpha.17.2 及之后的版本和 0.163.0-alpha 系列中，但不在稳定版 0.162.0 和 0.162.1 中，而 0.162.1 正是目前 npm 上的 latest。
在带修复的稳定版发布之前，CLI 的办法是使用上面的 sandbox = "unelevated"，或者安装已包含修复的 alpha 版本：
npm install -g @openai/codex@0.163.0-alpha.5
codex --versionalpha 版本可能带来其他改动。如果你的工作流依赖稳定性，优先使用 config.toml 中的权宜办法，并关注仓库的版本发布。
同一报错的其他原因怎么解决？
启动辅助程序时报 os error 5。在 2026年8月 OpenAI 论坛的一则反馈中，辅助程序无法从安装包的 WindowsApps 文件夹启动。有效的办法是在打开应用之前，让 Codex 指向另一份可执行文件：
setx CODEX_CLI_PATH "%USERPROFILE%\.codex\plugins\.plugin-appserver\codex.exe"先确认你的机器上存在这个文件；等新版安装包能正常启动辅助程序后，再删除这个变量。
失败只和某个文件夹有关。如果其他文件夹都正常，只有一个仓库出错，论坛上的另一则反馈通过 Windows 目录联接，把同一个仓库当作新路径打开，解决了问题：
mklink /J D:\CodexWorkspaceAlias D:\Projects\my-repository快速问答
不用沙箱直接运行命令能解决吗？能运行，但会去掉代理所有命令的保护，而且如果你的审批策略是细粒度的，这种请求可能被拒绝。先试 unelevated。
需要用 icacls 修改权限吗？不需要。有用户给运行时的 2,702 个文件授予了读取和执行权限，失败依旧一模一样：问题在于打开正在使用的文件，而不是文件拥有什么权限。
如果你想要一个直接在终端里运行的编程代理，没有桌面应用占用它自己运行时的文件，Verboo Code 以 CLI 形式运行，并提供无限 token。
