2026-10-08_Codex-Windows沙箱故障复盘报告

Codex for Windows 沙箱故障复盘报告

一、摘要

Codex 在 2026-10-07 的更新后，所有本地命令都无法执行：无论 PowerShell、cmd、Git 还是任意第三方程序，都在启动之前就被拒绝，报错固定为：

Failed to create unified exec process: helper_unknown_error: setup refresh had errors

真正的原因并不在这个报错里。沙箱日志显示，是沙箱预备流程 codex-windows-sandbox-setup.exe 新增的 runtime read/execute validation 步骤，在给 Codex 自带运行时目录里的 node.exe 更新安全描述符时，遇到 Windows 的 os error 32（ERROR_SHARING_VIOLATION，文件被另一程序占用），被判定为致命错误，导致 setup 退出码 1，命令执行器根本创建不起来。

该错误仅发生在 elevated（提权）沙箱模式下。同一台机器、同一个二进制、同一时刻，把 [windows] sandbox 改成 unelevated 后，沙箱命令立刻恢复正常——这构成了完整的对照实验证据，将根因锁定在 elevated provisioning 这条代码路径上。

在 codex features list 中，elevated_windows_sandbox 这一特性已被标记为 removed，而它对应的 provisioning 路径仍在被调用且已损坏。

二、故障现象

2.1 表层报错

Failed to create unified exec process: helper_unknown_error: setup refresh had errors

关键特征：报错发生在命令开始执行之前。日志中可见 CreateProcess 请求被 Rejected(…) 包装，命令内容与执行结果从未生成。

2.2 复现范围

"非沙箱通道正常 + 沙箱通道全挂"这个组合，从一开始就指向沙箱预备层，而非项目、依赖或网络。

2.3 失败次数统计

统计对象：%USERPROFILE%\\.codex\\.sandbox\\sandbox.YYYY-MM-DD.log 中 os error 32 的出现次数。

首次失败：2026-10-07T13:28:28Z（北京时间 21:28:28）
末次失败：2026-10-08T14:30:48Z（北京时间 22:30:48，修复配置前）

10-06 为零、10-07 突增到 96，与 10-07 的版本更新时间点完全吻合。

三、环境与版本信息

3.1 相关文件

3.2 被锁定的运行时是什么

…\\runtimes\\cua_node\\3dd31cfff853001c\\manifest.json：

{
"platform": "windows",
"arch": "x64",
"target": "windows-x64",
"node_version": "24.21.0-cua.1",
"node_binary_version": "24.21.0",
"node_archive_path": "v24.21.0-cua.1/node-v24.21.0-win-x64.zip",
"runtime_archive_name": "cua-node-0.0.29-20261003001300-807782c586fc-windows-x64.zip",
"runtime_archive_version": "0.0.29/20261003001300-807782c586fc",
"node_path": "bin/node.exe",
"node_modules": "bin/node_modules",
"node_repl_path": "bin/node_repl.exe"
}

bin/node_modules/@oai/ 下含 sky、cua、cua-repl、browser-desktop。

判定：cua_node 运行时就是 Codex「Computer Use（操作电脑 / 浏览器自动化）」的 Node 内核，node.exe 与 node_repl.exe 是该内核的常驻进程映像。

3.3 相关功能开关状态（codex features list）

四、证据链：从表层报错到真实错误

4.1 真实错误（日志原文）

setup_error.json 只有被包装后的结果：

{
"code": "helper_unknown_error",
"message": "setup refresh had errors"
}

真实错误在沙箱日志里：

runtime read/execute validation failed: validate runtime read/execute access on
C:\\Users\\[USER]\\AppData\\Local\\OpenAI\\Codex\\runtimes\\cua_node\\3dd31cfff853001c\\bin\\node.exe:
open ACL target for root-only update: 另一个程序正在使用此文件，进程无法访问。 (os error 32)

setup refresh: processed 0 write roots (read roots delegated); errors=[…]
setup refresh completed with errors: […]
setup error: setup refresh had errors
[codex-windows-sandbox-setup.exe] setup error: setup refresh had errors
[codex.exe] setup refresh: exited with status ExitStatus(ExitStatus(1))

os error 32 即 Windows ERROR_SHARING_VIOLATION，语义是"文件正被另一进程占用，无法以所请求的方式打开"。

4.2 完整调用链

用户发出命令
→ Codex 执行器请求创建进程（unified exec）
→ 先执行沙箱预备：codex-windows-sandbox-setup.exe（setup refresh）
→ 新增步骤：runtime read/execute validation
（以写 DACL 方式打开 runtime 目录下的每个可执行文件，确保沙箱账户可读可执行）
→ 打开 cua_node\\…\\bin\\node.exe 时命中 os error 32
→ setup 将该错误视为致命，进程退出码 1
→ 上层包装为 helper_unknown_error: setup refresh had errors
→ unified exec 拒绝创建进程
→ 命令在启动前即失败，不产生任何执行结果

4.3 时间线

4.4 一条容易被忽略的旁证

同一次 setup 中还出现了针对目录的同类错误：

failed to grant non-inheriting read-attributes ACE on user profile C:\\Users\\[USER]:
open ACL target for root-only update: 另一个程序正在使用此文件，进程无法访问。 (os error 32);
continuing setup

注意结尾的 continuing setup——这一条是非致命的，流程继续往下走。真正致命的是紧随其后的 runtime validation。

这条旁证的意义在于：说明 os error 32 并非"某个第三方进程长期霸占文件"这一简单情形，它在该路径中是可以被复现的模式（目录本身也被判为"占用"），因此不能用"找出并杀掉占用进程"来解决。

五、根因判定

根因：elevated（提权）Windows 沙箱的 provisioning 路径在当前版本中已损坏，但配置仍要求使用 elevated，导致每次命令执行前的沙箱预备必然失败。

支撑该判定的三项事实：

六、排除项

排查过程中逐一验证并排除的可能性：

七、决定性对照实验

在同一台机器、同一二进制、同一磁盘、同一时刻下，仅改变一个配置项：

实验 A 与 B 的唯一差异是 windows.sandbox 的取值，结果完全相反。这排除了安装完整性、磁盘位置、项目内容、外部进程占用等一切与"环境"相关的解释，将根因锁定在 elevated provisioning 代码路径。

补充探测（同一时段）：

cua node.exe WRITE_DAC open -> OK
node_repl.exe WRITE_DAC open -> OK
user profile dir WRITE_DAC open -> OK

八、修复与验证

8.1 修复动作

文件：%USERPROFILE%\\.codex\\config.toml

# 修改前
[windows]
sandbox = "elevated"

# 修改后
[windows]
sandbox = "unelevated"

改动前已备份为 config.toml.bak-20261008-222432。

8.2 验证结果

九、风险、代价与回退

9.1 代价

elevated 是官方文档中推荐的加固模式，unelevated 是其较弱的回退模式。本次修复本质上是用沙箱隔离强度换取可用性。

在当前版本下，elevated 已被证明无法工作，因此实际选项只有"降级使用"或"停用等待官方修复"。

9.2 回退方法

官方发布修复后，把配置改回即可：

[windows]
sandbox = "elevated"

或直接还原备份：config.toml.bak-20261008-222432。

9.3 附带修复

config.toml 中的 notify 钩子指向一个已不存在的运行时目录：

C:\\Users\\[USER]\\AppData\\Local\\OpenAI\\Codex\\runtimes\\cua_node\\71e3f41277f96d73\\…

磁盘上 runtimes\\cua_node 下仅剩 3dd31cfff853001c，71e3f41277f96d73 经全盘检索确认不存在——属 10-07 更新重建运行时后未同步配置所留的悬空引用。已注释并注明原因。

9.4 其他观察（不影响主流程）

• 运行 Codex CLI 时持续出现 WARNING: failed to clean up stale arg0 temp dirs: 拒绝访问。 (os error 5)，属另一处权限问题，未影响功能，暂未处理。
• codex doctor 报告的 sandbox 失败读的是已记录的 setup_error.json（时间戳为修复前），不会重新执行 provisioning。因此要判断"是否修好"必须使用 codex sandbox <命令> 实测，不能依赖 doctor 的结论。

十、给 OpenAI 的报障材料（可直接复制）

Title: Windows: all local commands fail with helper_unknown_error: setup refresh had errors
(elevated sandbox provisioning broken; os error 32 on cua_node runtime)

Product: Codex Desktop / Codex CLI for Windows
Codex CLI version: 0.162.0-alpha.2 (windows-x86_64)
Windows: 10.0.26200.9457 (Windows 11 Core), x64, zh-CN
Sandbox mode in config: [windows] sandbox = "elevated"

Summary:
Since the 2026-10-07 update, every local command fails BEFORE the process starts.
Approved (non-sandboxed) execution still works, which isolates the failure to the
sandbox provisioning layer.

User-visible error:
Failed to create unified exec process: helper_unknown_error: setup refresh had errors

Underlying error (from %USERPROFILE%\\.codex\\.sandbox\\sandbox.2026-10-07.log and
sandbox.2026-10-08.log, 140 occurrences total):

runtime read/execute validation failed: validate runtime read/execute access on
C:\\Users\\[USER]\\AppData\\Local\\OpenAI\\Codex\\runtimes\\cua_node\\3dd31cfff853001c\\bin\\node.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)

setup refresh completed with errors: […]
setup error: setup refresh had errors
[codex-windows-sandbox-setup.exe] setup error: setup refresh had errors
[codex.exe] setup refresh: exited with status ExitStatus(ExitStatus(1))

Counts: 2026-10-06 = 0, 2026-10-07 = 96, 2026-10-08 = 44 (all before the workaround).
First failure: 2026-10-07T13:28:28Z, ~70 minutes after the update was installed.

Controlled experiment (same machine, same binary, same disk, same moment):
A) codex -c windows.sandbox=unelevated sandbox cmd.exe … -> SUCCEEDS
B) codex sandbox cmd.exe … (config = elevated) -> FAILS (setup refresh had errors)
C) codex -c windows.sandbox=elevated -c features.computer_use=false sandbox … -> FAILS

The only difference between A and B is the value of windows.sandbox.
This rules out installation integrity, disk location, project content and
third-party file locks. `codex doctor` reports only one failure:
"elevated Windows sandbox provisioning recorded a structured failure"
(all other checks pass: install consistent, runtime, state databases, disk).

Additional findings:
– `codex features list` shows elevated_windows_sandbox = removed, yet
`[windows] sandbox = "elevated"` still triggers that provisioning path.
– Real-time WRITE_DAC open probes on node.exe, node_repl.exe and C:\\Users\\[USER]
all SUCCEED when idle, so no external process holds these objects; the sharing
violation is produced by the elevated path itself.
– Pre-granting CodexSandboxUsers read/execute does NOT help: node.exe already has
[HOST]\\CodexSandboxUsers:(I)(RX). The validation step opens the ACL target
unconditionally.
– `unified_exec` cannot be disabled (–disable unified_exec and
-c features.unified_exec=false are both ignored; effective state stays true).
– The affected runtime is the Computer Use Node kernel
(manifest: cua-node-0.0.29, node 24.21.0-cua.1, ships @oai/sky, @oai/cua,
@oai/cua-repl, @oai/browser-desktop).

Requested: fix elevated Windows sandbox provisioning, and surface the underlying
os error 32 / offending path instead of the generic "setup refresh had errors".

十一、排查命令速查

# 本地体检（注意：sandbox 一项读的是历史记录，不代表当前状态）
codex doctor

# 查看功能开关及其有效状态
codex features list
codex –disable <feature> features list # 验证某开关是否可被覆盖

# 直接实测沙箱是否可用（判断修复是否生效的唯一可靠方式）
codex sandbox hostname.exe
codex -c windows.sandbox=unelevated sandbox hostname.exe
codex -c windows.sandbox=elevated sandbox hostname.exe

# 查看真实错误（表层报错无信息量，必须看这里）
tail -30 "%USERPROFILE%\\.codex\\.sandbox\\sandbox.$(date +%F).log"
cat "%USERPROFILE%\\.codex\\.sandbox\\setup_error.json"

# 统计失败次数
grep -c "os error 32" "%USERPROFILE%\\.codex\\.sandbox\\sandbox."*.log

注意事项

• 在 Git Bash 中调用 cmd.exe /d /c 时，/d、/c 会被 MSYS 路径转换为 D:/、C:/，导致 cmd 以交互模式启动并挂起等待输入。测试时请使用不依赖参数的命令（如 hostname.exe），或改用 PowerShell 语法。
• codex doctor 的 sandbox 检查项不会重新执行 provisioning，不能用于判断修复效果。