# Codex Windows 沙箱 os error 32：CLI 0.163.0、桌面版 26.1007 已修复

> Windows 上 Codex 沙箱报 os error 32 是它自身的 bug：CLI 升到 0.163.0、桌面版升到 26.1007.21434 后完全重启；unelevated 只是临时绕过。

- Source: https://www.aifreeapi.com/zh/posts/codex-windows-sandbox-error-32
- Language: zh
- Published: 2026-10-22
- Updated: 2026-10-22
- Publisher: AI Free API (https://www.aifreeapi.com)

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`（[微软错误码表](https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-)）。它的 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](https://github.com/openai/codex/pull/51822)（“Avoid sharing violations when repairing Windows runtime ACLs”，10 月 7 日合并）里改成只对目录使用 `MAXIMUM_ALLOWED`，对文件只在确实需要改 ACL 时申请 `READ_CONTROL | WRITE_DAC`。

这个 bug 在不同入口的表现不一样，以下几种都是它（来自 [#51601](https://github.com/openai/codex/issues/51601) 和 [#52328](https://github.com/openai/codex/issues/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\` 下：

```text
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`：

```text
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](https://github.com/openai/codex/issues/54635) 的日志里，0.163.0 的刷新就是先出这行再成功），不用管它。

![沙箱日志四种行的判断：runtime read/execute validation failed 指向 node_repl.exe 的 os error 32 是致命错误，要升级到 CLI 0.163.0、桌面版 26.1007.21434；user profile 那行以 continuing setup 结尾，无害；CreateProcessSecurityEnvironment failed (HRESULT = 0x80070020) 是 MXC 路径上的另一个问题；setup refresh: spawning 指向 OpenAI\Codex\bin 下且该 codex.exe 为 0.162.0-alpha.2 时，要改 CODEX_CLI_PATH](https://www.aifreeapi.com/posts/zh/codex-windows-sandbox-error-32/img/log-lines.webp)

日志里如果是下面这些，就不是本文这个 bug，升级未必解决：

| 报错或日志 | 实际含义 | 处理方向 |
| --- | --- | --- |
| error 5、`helper_sandbox_lock_failed`、`SetNamedSecurityInfoW ... failed: 5` | 拒绝访问，和 ACL 或文件所有者有关 | 网上“改所有者、跑 icacls”的做法针对的是它，不是 error 32 |
| error 1385 | Windows 拒绝沙箱用户需要的登录类型 | 按[官方 Windows 沙箱文档](https://learn.chatgpt.com/docs/windows/windows-sandbox)请 IT 授予登录权限，急用时临时改 `unelevated` |
| error 740 | 操作需要提升权限 | 按报错原文另查 |
| `CreateProcessAsUserW failed` | 沙箱进程创建失败 | 按报错原文另查 |
| `CreateProcessSecurityEnvironment failed (HRESULT = 0x80070020)` | 0x20 同样是 32，但发生在 MXC 沙箱路径上，见于桌面版 26.1013.x | 0.163.0 的修复管不到它，截至 10 月 22 日仍未修复（[#55230](https://github.com/openai/codex/issues/55230)） |

## Codex 修复版本对照：版本号更大不等于修好了

CLI 这边，修复进了 [Codex CLI 0.163.0](https://github.com/openai/codex/releases/tag/rust-v0.163.0)：10 月 15 日发布，版本说明里列着“#51822 Avoid sharing violations when repairing Windows runtime ACLs”，npm 上 `@openai/codex` 的 `latest` 也是这一版。OpenAI 员工 10 月 16 日在 [#54325](https://github.com/openai/codex/issues/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 的源码](https://github.com/openai/codex/blob/rust-v0.162.1/codex-rs/windows-sandbox-rs/src/acl.rs)里看到，找不到“Only directories need MAXIMUM_ALLOWED”这句注释），而预发布版 0.162.0-alpha.17.2 通过单独合入（cherry-pick）带上了它。于是会出现一个反直觉的组合：桌面版自带的 0.162.0-alpha.17.2 没问题，你用 npm 装的、版本号看起来更新的 0.162.1 却还在报错。

![Codex 修复版本对照：npm 或独立 CLI 的 0.161.0、0.162.0、0.162.1 仍报错，0.163.0 已修复；桌面版 26.1002.x（自带 CLI 0.162.0-alpha.2）仍报错，26.1007.21434（自带 CLI 0.162.0-alpha.17.2）已修复](https://www.aifreeapi.com/posts/zh/codex-windows-sandbox-error-32/img/fixed-versions.webp)

桌面版这边，多名用户在 #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 和后台进程都要换新

1. 更新桌面版：用应用内更新或 Microsoft Store 更新，装好后让应用重启，在“关于 Codex”里确认版本是 26.1007.21434 或更新。
2. 如果你还用 npm 装过 CLI，一起升级：

   ```powershell
   npm install -g @openai/codex@latest
   codex --version
   ```

   输出应为 `codex-cli 0.163.0` 或更高。只装过桌面版、从没用过 npm 版的可以跳过这步。
3. 把所有 Codex 进程完全退出：关掉桌面版和 ChatGPT 桌面应用、所有终端里的 `codex` 会话、正在用 Codex 插件的 VS Code。打开任务管理器，确认没有残留的 `codex.exe` 和 `node_repl.exe`。只关窗口不够：CLI 的后台 daemon 不重启，跑的就还是旧版本（它的版本文件夹在 `%USERPROFILE%\.codex\packages\app-server-daemon\releases\` 下）。
4. 重新打开 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 的这条回复](https://github.com/openai/codex/issues/51601#issuecomment-6183922808)）。

办法就是把 CLI 升到 0.163.0。用 VS Code 插件，或者有别的工具在调用 `codex` 的，也属于这种情况。

### 无人值守的 codex app-server 会话：命令全失败，回答看起来却正常

用脚本或其他工具以非交互方式启动 `codex app-server` 时（例如 Claude Code 的 codex-companion 审查脚本），会话一开始就会拉起自己的 `node_repl.exe`。在旧版 CLI 上，这个会话里的每一条 shell 命令都会失败，退出码 -1，跟桌面版开没开无关（[#54138](https://github.com/openai/codex/issues/54138)）。

更要当心的是，模型不会因此停下来，它会只凭手上已有的上下文给出结论，没读过文件、也没跑过 `git`。只看最终输出的话，结果看起来完全正常。如果你在自动化流程里用 Codex 做审查或分析，升级之前的结论要重新跑一遍。

### CODEX_CLI_PATH 还指着旧 CLI

有一份附带完整日志的报告（[#54635](https://github.com/openai/codex/issues/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](/zh/posts/codex-app-server-failed-to-start)。

## 验证 Codex 沙箱已修好：开着桌面版跑一条沙箱命令

验证时桌面版要开着。这个 bug 只在 `node_repl.exe` 运行时出现，桌面版关着的话，连有问题的旧版本也能通过测试。在 PowerShell 里运行：

```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`（[复现记录](https://github.com/openai/codex/issues/51601#issuecomment-6114102761)）。

CLI 0.162.0 及以上也可以用官方文档里的写法，它会带上托管配置和 workspace 权限：

```powershell
codex sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo SANDBOX_OK
$LASTEXITCODE
```

`codex 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 沙箱文档](https://learn.chatgpt.com/docs/windows/windows-sandbox)现在把 `mxc` 列为兼容设备上的推荐沙箱，它不需要管理员批准的设置，也不创建额外的 Windows 账户，`elevated` 则降为它不可用时的首选后备。MXC 需要 Windows 11 24H2（build 26100.9278）或 25H2（build 26200.9278）及以上。桌面版在设备支持时会为个人账号自动优先使用 MXC。

CLI 0.162.0 及以上可以先只测一条命令，不改保存的设置：

```powershell
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` 里打开：

```toml
[features]
prefer_mxc = true
```

注意 MXC 路径上目前有另一个未修复的问题：桌面版 26.1013.x 上有人遇到 `CreateProcessSecurityEnvironment failed (HRESULT = 0x80070020)`，只在优先使用 MXC 时复现（[#55230](https://github.com/openai/codex/issues/55230)）。企业设备也可能用 `allow_mxc = false` 禁用了它。

### unelevated：能让命令先跑起来，但隔离变弱

```toml
[windows]
sandbox = "unelevated"
```

它的代价写在官方文档里：命令以从你当前用户派生出的受限令牌运行，网络隔离比 `elevated` 弱，也不支持禁止读取的路径（配了禁止读取规则的自定义权限配置会拒绝启动）。文档对它的定位是 `elevated` 无法设置、且单位策略允许时的后备；管理员可以用 `allowed_sandbox_implementations` 禁止它。社区里的效果也不一致：有人改完立刻恢复，有人改完仍然失败（报 `cannot enforce split writable root sets`），还有人要同时把 `sandbox_mode` 设为 `"workspace-write"` 才行。

升级到修复版之后，把它改回 `elevated` 或删掉这一行，再按上面的方法验证一次。`config.toml` 在哪、沙箱模式和批准设置各管什么，见[Codex 沙箱与 config.toml：权限、批准和网络怎么配](/zh/posts/codex-config-toml)。

## 修复版上仍报错：反馈给 OpenAI 时附上这些

如果各组件都已是修复版、残留也查过，日志里仍是那行致命的 `os error 32`，可以到 [openai/codex 的 issue 区](https://github.com/openai/codex/issues)反馈。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](/zh/posts/codex-app-server-failed-to-start)。