Windows 上的 Codex 突然什么都执行不了：Get-Location、读文件、Node REPL、Computer Use、浏览器操作都在开始前失败，报 helper_unknown_error: setup refresh had errors，重启应用、重开机都不管用。如果沙箱日志里同时有一行以 (os error 32) 结尾、指向 node_repl.exe 或 VCRUNTIME140_1.dll，那就是 2026 年 10 月 7 日前后随 Codex 更新出现的 bug，不是你的项目、权限或 config.toml 写错了。
根本的修法是：把本机所有 Codex 组件都升到已修复的版本，再把 Codex 相关进程全部退出、重新打开。截至 2026 年 10 月 22 日，各组件的版本是这样的：
| 组件 | 怎么看版本 | 仍会报 os error 32 | 已修复 |
|---|---|---|---|
| Codex 桌面版（含 ChatGPT 桌面应用里的 Codex） | 应用内“关于 Codex”窗口 | 26.1002.x（如 26.1002.51308、26.1002.52244） | 26.1007.21434（build 13901）及更新 |
| 桌面版自带的 CLI | 对 %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe 运行 --version | 0.162.0-alpha.2 | 0.162.0-alpha.17.2 及更新 |
| npm 或单独安装的 Codex CLI | codex --version | 0.161.0、0.162.0、0.162.1 | 0.163.0 及更新 |
CLI 的修复版本有 OpenAI 的版本说明和员工回复作依据；桌面版 26.1007.21434 是多名用户升级后确认的，OpenAI 没有正式说明桌面版从哪一版起修好。把 [windows] sandbox 改成 unelevated 能让命令先跑起来，但它会削弱隔离，只适合升级前临时用，升级后要改回来。
os error 32 是什么：Codex 自己占着 node_repl.exe
Windows 系统错误 32 是 ERROR_SHARING_VIOLATION（0x20），意思是“另一个程序正在使用此文件，进程无法访问”，英文原句就是日志里那句 The process cannot access the file because it is being used by another process（微软错误码表）。它的 HRESULT 写法是 0x80070020，后面会用到。
用 elevated 沙箱时，Codex 每次执行命令前都会做一次沙箱设置刷新（setup refresh），由 codex-windows-sandbox-setup.exe 检查 Codex 自带运行时目录 %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>\ 的权限。出问题的版本用 MAXIMUM_ALLOWED（申请尽可能多的访问权限）去打开这个目录里正在运行的 node_repl.exe 和已被加载的 VCRUNTIME140_1.dll，Windows 以“文件正被占用”拒绝，刷新失败，命令根本没开始。
麻烦在于占着这些文件的正是 Codex 自己：桌面版在第一条命令之前就启动了 node_repl.exe（Node REPL 服务），codex-computer-use-swift.exe 加载着那个 DLL。所以旧版设置程序在桌面版开着的时候永远过不去。OpenAI 在 PR #51822（“Avoid sharing violations when repairing Windows runtime ACLs”，10 月 7 日合并）里改成只对目录使用 MAXIMUM_ALLOWED，对文件只在确实需要改 ACL 时申请 READ_CONTROL | WRITE_DAC。
这个 bug 在不同入口的表现不一样，以下几种都是它（来自 #51601 和 #52328 里的多份报告）：
- 执行命令：
Failed to create unified exec process: helper_unknown_error: setup refresh had errors，或exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors。 - Node REPL、Computer Use、浏览器操作：
windows sandbox failed: helper_unknown_error: setup refresh had errors，接着是trusted Node process exited unexpectedly或node_repl kernel exited unexpectedly。 - 桌面版英文界面可能显示 “Windows setup didn't finish”或“Setup stopped”，点 Retry 不会弹出管理员确认（UAC）窗口。
受影响的主要是 [windows] sandbox = "elevated" 的机器，Windows 10 和 Windows 11 都有。
沙箱日志里哪一行 os error 32 才是致命的
沙箱日志在 %USERPROFILE%\.codex\.sandbox\ 下，按日期命名为 sandbox.<YYYY-MM-DD>.log（官方文档写作 CODEX_HOME/.sandbox/sandbox.log；设置过 CODEX_HOME 的话去那个目录找）。打开当天的文件搜 os error 32，可能会看到两种完全不同的行。
致命的是这一行，开头是 runtime read/execute validation failed，目标在 runtimes\cua_node\ 下：
runtime read/execute validation failed: validate runtime read/execute access on C:\Users\<用户名>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node_repl.exe: open ACL target for root-only update: The process cannot access the file because it is being used by another process. (os error 32)目标也可能是 ...\bin\node_modules\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll。它后面紧跟着 setup refresh: ... errors=["runtime read/execute validation failed: ..."] 和 top-level error: setup refresh had errors。中文版 Windows 上中间那句会显示成中文，认准 runtime read/execute validation failed 和结尾的 (os error 32) 就行。
无害的是这一行，目标是用户目录，结尾写着 continuing setup：
failed to grant non-inheriting read-attributes ACE on user profile C:\Users\<用户名>: open ACL target for root-only update ... (os error 32); continuing setup设置会继续往下走，最后照样可以得到 errors=[]。已修复的版本上也能看到它（#54635 的日志里，0.163.0 的刷新就是先出这行再成功），不用管它。
日志里如果是下面这些，就不是本文这个 bug，升级未必解决：
| 报错或日志 | 实际含义 | 处理方向 |
|---|---|---|
error 5、helper_sandbox_lock_failed、SetNamedSecurityInfoW ... failed: 5 | 拒绝访问，和 ACL 或文件所有者有关 | 网上“改所有者、跑 icacls”的做法针对的是它，不是 error 32 |
| error 1385 | Windows 拒绝沙箱用户需要的登录类型 | 按官方 Windows 沙箱文档请 IT 授予登录权限，急用时临时改 unelevated |
| error 740 | 操作需要提升权限 | 按报错原文另查 |
CreateProcessAsUserW failed | 沙箱进程创建失败 | 按报错原文另查 |
CreateProcessSecurityEnvironment failed (HRESULT = 0x80070020) | 0x20 同样是 32，但发生在 MXC 沙箱路径上，见于桌面版 26.1013.x | 0.163.0 的修复管不到它，截至 10 月 22 日仍未修复（#55230） |
Codex 修复版本对照：版本号更大不等于修好了
CLI 这边，修复进了 Codex CLI 0.163.0：10 月 15 日发布，版本说明里列着“#51822 Avoid sharing violations when repairing Windows runtime ACLs”，npm 上 @openai/codex 的 latest 也是这一版。OpenAI 员工 10 月 16 日在 #54325 里回复：这是 #51822 修掉的 Windows 沙箱问题，修复包含在 0.163.0 里；0.161.0 和 0.162.1 仍有这个问题，所以降级没用；请升级到 0.163.0 或更高，并重启 Codex，包括正在运行的桌面版和 daemon 进程。
容易看错的是 0.162 这一段。0.162.0 和 0.162.1 两个正式版的 acl.rs 里没有这段修改（可以在 0.162.1 的源码里看到，找不到“Only directories need MAXIMUM_ALLOWED”这句注释），而预发布版 0.162.0-alpha.17.2 通过单独合入（cherry-pick）带上了它。于是会出现一个反直觉的组合：桌面版自带的 0.162.0-alpha.17.2 没问题，你用 npm 装的、版本号看起来更新的 0.162.1 却还在报错。
桌面版这边，多名用户在 #51601 里确认升级到 26.1007.21434（build 13901，Windows 包版本显示为 26.1007.2314.0）后错误消失：elevated 沙箱不用改，除了装更新、让应用重启，没做任何别的操作；其中有人用的是带禁止读取规则的 Business 账号，日志显示 errors=[]。26.1007.x 自带的 CLI 正是 0.162.0-alpha.17.2，和上面的源码情况对得上。
有两点要知道：
- OpenAI 的更新日志里，26.1007 那条没有提这项修复；26.1002 那条写着“Fixed Windows sandbox refresh failures after app updates”，但之后的 26.1002 安装包上仍然有人报 error 32，所以那句话说的不是这个问题。
- 自动更新不保证你已经拿到修复版。10 月 11 日还有 Windows 10 用户的桌面版停在 26.1002.7124.0，应用自更新装上的仍是 0.162.0-alpha.2 的 CLI。以“关于 Codex”窗口里的版本号为准。
VS Code 插件没有单独公布修复版本。更新插件之后，用后面“验证”一节的方法看日志是否变成 errors=[]。
升级 Codex：桌面版、npm CLI 和后台进程都要换新
-
更新桌面版：用应用内更新或 Microsoft Store 更新，装好后让应用重启，在“关于 Codex”里确认版本是 26.1007.21434 或更新。
-
如果你还用 npm 装过 CLI，一起升级：
powershellnpm install -g @openai/codex@latest codex --version输出应为
codex-cli 0.163.0或更高。只装过桌面版、从没用过 npm 版的可以跳过这步。 -
把所有 Codex 进程完全退出：关掉桌面版和 ChatGPT 桌面应用、所有终端里的
codex会话、正在用 Codex 插件的 VS Code。打开任务管理器，确认没有残留的codex.exe和node_repl.exe。只关窗口不够：CLI 的后台 daemon 不重启，跑的就还是旧版本（它的版本文件夹在%USERPROFILE%\.codex\packages\app-server-daemon\releases\下）。 -
重新打开 Codex，按后面“验证”一节跑一条沙箱命令。
升级后还是 os error 32：查这三处残留
桌面版已修好，npm CLI 还停在 0.162.1
“更新了还报错”先查这一种。cua_node 运行时目录在 %LOCALAPPDATA%\OpenAI\Codex\ 下，由桌面版管理，但 npm 版 CLI 自己做沙箱设置刷新时也会去检查它。桌面版开着、node_repl.exe 在跑，0.162.1 的 CLI 就照样撞上 error 32；单独给 CLI 设一个 CODEX_HOME 也隔离不了，因为这个目录根本不在 CODEX_HOME 里。把桌面版完全关掉后同一条 CLI 命令又能成功，这很容易让人误以为是桌面版的问题（#51601 的这条回复）。
办法就是把 CLI 升到 0.163.0。用 VS Code 插件，或者有别的工具在调用 codex 的，也属于这种情况。
无人值守的 codex app-server 会话：命令全失败，回答看起来却正常
用脚本或其他工具以非交互方式启动 codex app-server 时（例如 Claude Code 的 codex-companion 审查脚本），会话一开始就会拉起自己的 node_repl.exe。在旧版 CLI 上，这个会话里的每一条 shell 命令都会失败，退出码 -1，跟桌面版开没开无关（#54138）。
更要当心的是，模型不会因此停下来，它会只凭手上已有的上下文给出结论，没读过文件、也没跑过 git。只看最终输出的话，结果看起来完全正常。如果你在自动化流程里用 Codex 做审查或分析，升级之前的结论要重新跑一遍。
CODEX_CLI_PATH 还指着旧 CLI
有一份附带完整日志的报告（#54635，CLI 0.163.0 搭配桌面版 26.1002.52244）找到了另一种残留：Node REPL 和 Computer Use 启动时用的 CODEX_CLI_PATH 被写死在两个文件里，更新后仍指向旧的 0.162.0-alpha.2：
%USERPROFILE%\.codex\config.toml中的[mcp_servers.node_repl.env]%USERPROFILE%\.codex\plugins\cache\openai-bundled\unified-computer-use\<版本>\.mcp.json
这样一来，就算新版已经装好，刷新时调用的仍是旧版设置程序。检查方法：在当天的沙箱日志里，找失败那次刷新之前的 setup refresh: spawning 行，看它启动的是哪个 codex-windows-sandbox-setup.exe。路径如果在 %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\ 下，对同一文件夹里的 codex.exe 运行 --version；显示 0.162.0-alpha.2，就是这个问题。
报告里的修法是：先备份这两个文件，把 CODEX_CLI_PATH 改成最新的 codex.exe（报告中位于 %USERPROFILE%\.codex\packages\app-server-daemon\releases\<版本>\bin\ 下，改之前用 --version 确认），然后完全重启 Codex。这只是一位用户的报告，OpenAI 还没有回复，各人机器上的目录结构也可能不同；报告者还提到，之后的更新可能把旧值写回去，所以每次更新后都要再看一眼。同一个变量指向的文件夹被更新删掉时，症状是另一种报错 os error 3，见Codex app-server 启动失败：按报错原文对症修，先别删 .codex。
验证 Codex 沙箱已修好：开着桌面版跑一条沙箱命令
验证时桌面版要开着。这个 bug 只在 node_repl.exe 运行时出现，桌面版关着的话，连有问题的旧版本也能通过测试。在 PowerShell 里运行：
codex sandbox cmd /c "cd && echo SANDBOX-OK"
$LASTEXITCODE成功的标准是：输出当前目录和 SANDBOX-OK，$LASTEXITCODE 为 0，沙箱日志里新增一行 setup refresh: processed N write roots (read roots delegated); errors=[]。旧版本在同样条件下会以退出码 1 结束，日志里出现上文那行致命的 os error 32（复现记录）。
CLI 0.162.0 及以上也可以用官方文档里的写法，它会带上托管配置和 workspace 权限：
codex sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo SANDBOX_OK
$LASTEXITCODEcodex sandbox 的参数随版本变化，一种写法报参数错误时换另一种。只用桌面版的话，新开一个对话让 Codex 运行 Get-Location：命令正常返回、日志里是 errors=[]，再试一次 Node REPL 或 Computer Use 能否启动，就算修好了。
这些做法解决不了 os error 32
- 重启应用、重启 Windows、开新对话：设置程序还是旧的，
node_repl.exe一启动就会再次失败。 - 卸载重装、应用修复或重置：有用户试过都没用；
CODEX_CLI_PATH这类残留也不会因重装被改写。 - 结束
node_repl.exe进程：只能撑到下一个内核启动；就算撑住了，错误也会挪到被codex-computer-use-swift.exe占用的VCRUNTIME140_1.dll上，而桌面版会立刻把它重新拉起来。 - 手动给
node_repl.exe加读取和执行权限、改所有者、跑 icacls：沙箱用户组本来就有读取和执行权限，问题在于文件正被占用。有人加了明确的权限条目后测试，结果毫无变化。 - 把 npm CLI 降到 0.161.0：OpenAI 员工已确认 0.161.0 同样有问题。
- 把桌面版降回 9 月的 26.930.x：那一版还没有这个回归，但修复版已经发布，退回去只会错过之后的修复。
- 长期开完全访问（
danger-full-access）或关闭 Defender 等安全防护：都不针对这个问题，只会去掉本来的保护。
暂时没法升级 Codex：MXC 和 unelevated 各有代价
公司电脑等不到更新、或者修复版还没推到你这里时，有两个临时选项。
Windows 11 新版本上先试 MXC
官方 Windows 沙箱文档现在把 mxc 列为兼容设备上的推荐沙箱，它不需要管理员批准的设置，也不创建额外的 Windows 账户，elevated 则降为它不可用时的首选后备。MXC 需要 Windows 11 24H2（build 26100.9278）或 25H2（build 26200.9278）及以上。桌面版在设备支持时会为个人账号自动优先使用 MXC。
CLI 0.162.0 及以上可以先只测一条命令，不改保存的设置：
codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
$LASTEXITCODE输出 MXC_OK 且退出码为 0，就可以在 config.toml 里打开：
[features]
prefer_mxc = true注意 MXC 路径上目前有另一个未修复的问题：桌面版 26.1013.x 上有人遇到 CreateProcessSecurityEnvironment failed (HRESULT = 0x80070020)，只在优先使用 MXC 时复现（#55230）。企业设备也可能用 allow_mxc = false 禁用了它。
unelevated：能让命令先跑起来，但隔离变弱
[windows]
sandbox = "unelevated"它的代价写在官方文档里：命令以从你当前用户派生出的受限令牌运行，网络隔离比 elevated 弱，也不支持禁止读取的路径（配了禁止读取规则的自定义权限配置会拒绝启动）。文档对它的定位是 elevated 无法设置、且单位策略允许时的后备；管理员可以用 allowed_sandbox_implementations 禁止它。社区里的效果也不一致：有人改完立刻恢复，有人改完仍然失败（报 cannot enforce split writable root sets），还有人要同时把 sandbox_mode 设为 "workspace-write" 才行。
升级到修复版之后，把它改回 elevated 或删掉这一行，再按上面的方法验证一次。config.toml 在哪、沙箱模式和批准设置各管什么，见Codex 沙箱与 config.toml：权限、批准和网络怎么配。
修复版上仍报错：反馈给 OpenAI 时附上这些
如果各组件都已是修复版、残留也查过，日志里仍是那行致命的 os error 32，可以到 openai/codex 的 issue 区反馈。OpenAI 员工和官方文档要的材料是：
- 一份新的沙箱日志（
%USERPROFILE%\.codex\.sandbox\下当天的文件）； - CLI 的版本（
codex --version）和 daemon 或桌面版的版本； - 当前用的沙箱实现：
mxc、elevated还是unelevated； - Windows 的 build 号，以及是 Windows 10 还是 Windows 11。
不要发送 %USERPROFILE%\.codex\.sandbox-secrets\ 里的任何内容。
截至 2026 年 10 月 22 日，还有几件事没有定论：OpenAI 没有正式说明桌面版从哪一版起修复；CODEX_CLI_PATH 停在旧路径的问题，后续更新会不会自动纠正；MXC 路径上的 0x80070020 何时修复。如果你的 Codex 连启动都启动不了，而不是命令执行失败，那是另一类问题，见Codex app-server 启动失败：按报错原文对症修，先别删 .codex。
