Codex Windows 沙箱启动失败？先判该用 MXC 还是旧实现

Codex 在 Windows 上一执行命令就报沙箱错误，先确认当前选的是 MXC、旧版 elevated，还是旧版 unelevated。三者的启动条件不同：反复批准旧版 setup，不能给设备补出 MXC 原生能力；看到 1385，也不能直接归因于 Windows 版本太旧。

本文处理“Codex Windows 沙箱初始化失败”、codex sandbox setup failed、MXC 不支持和 Windows 错误 1385。目标是先让获准的实现启动，再验证任务所需的访问范围；两项分别验收。

核验范围： 2026-10-22 重新核对本文列出的 OpenAI 官方资料。本机为 macOS，可核对 CLI 帮助和文章示例，但没有 Windows 实机，未运行 MXC、UAC 初始化、域策略或下述 PowerShell 测试；这些步骤及预期结果依据当前官方机制编写，不是 Windows 实测记录。

先按错误现象分流

当前现象	优先检查	通过标准
显式选 MXC 后提示能力不可用或被策略禁止	第 1—3 步：实际执行端、版本、设备能力与组织要求	对应设备的 MXC 探针输出标记，退出码为 0
`sandbox setup failed`，出现 UAC、账户或防火墙相关错误	第 4 步：确认是旧版 elevated 初始化	获准的 setup 完成后，普通用户会话能启动命令
沙箱用户已创建，但启动命令报 `1385`	第 5 步：沙箱用户所需登录类型的策略权限	IT 处理有效策略后，同一员工环境重试成功
自动切到 unelevated，担心隔离不符合要求	第 2、4 步：回退选择与组织允许范围	确认实现及其能力符合任务要求，不能只看“能跑”
`MXC_OK` 成功，项目仍无法写文件或联网	第 6 步：单独验证文件、网络和普通会话	获准操作成功；受限操作仍被拒绝
更新或移动仓库后才失败	第 1、7 步：真实版本、目录、有效策略及启动记录	在新位置重新启动并重复对应检查

若命令已经启动，只是找不到 npm、node、python，转到任务执行环境与 PATH 排查；不要把所有命令错误都当成沙箱初始化故障。

1. 先确认是 Windows 原生执行，以及实际使用的版本

适用条件： 使用桌面端、CLI 或 IDE 扩展，尚未确认命令究竟在哪一端运行。

先记录客户端名称与版本、Windows 10/11、winver 显示的版本和完整 OS build、执行用户及工作目录。CLI 在实际执行命令的 Windows PowerShell 中检查：

codex --version
Get-Command codex -All | Select-Object CommandType, Source
Get-Location

预期能确认启动了哪个 Codex、来自哪个安装位置、在哪个目录工作。若列出多个安装源或更新后版本未变，先按版本与启动路径排查处理。桌面端内置代理和单独安装的 CLI 也可能版本不同，外部 CLI 的成功不能证明桌面端已修复。

当前官方 Windows 桌面端文档使用“ChatGPT desktop app”名称，相关 Codex 路径仍保留。其 Windows 原生代理默认通过 PowerShell 执行；设置中切到 WSL 后还需重启应用。集成终端与代理的选择独立，打开 WSL 终端不等于代理已经在 WSL 中运行。

如果实际执行端是 WSL2、SSH Linux 主机或云端容器，应检查该端的沙箱，本文的 Windows MXC／1385 路径不直接适用。原生 Windows 默认配置目录是 %USERPROFILE%\.codex；若设置了 CODEX_HOME，以实际目录为准。WSL CLI 默认使用 Linux 用户目录，不自动共享这些配置。

失败后怎么办： 先把执行端、路径和版本核清，再选下一条分支；不要在 Windows 配置文件里修改一个实际运行于 WSL 的会话。

2. MXC、elevated、unelevated 怎么选？先核设备和组织边界

当前 Windows 沙箱指南列出三种实现。实现负责如何隔离进程；权限配置负责能访问哪些文件和网络；审批策略负责何时询问更多权限，这三层要分别看。

实现	启动条件与用途	需要特别确认的边界
`mxc`	兼容设备的推荐实现，使用 Microsoft Execution Containers 原生进程隔离	不需要管理员批准的 setup、额外 Windows 账户或本地防火墙规则，但设备和有效策略必须支持
`elevated`	MXC 不可用或被禁用时，优先考虑的旧版回退	初始化需要管理员批准；沙箱内命令本身以非管理员权限运行
`unelevated`	elevated 初始化不可用，且组织允许时的旧版回退	网络隔离较弱，不支持 denied read paths；不能当作与另两种实现等价的修复

Windows build 是检查起点，探针才检查当前设备

官方给出的 MXC 原生能力引入版本为 Windows 11 24H2 build 26100.9278、25H2 build 26200.9278，能力仍按设备推出。宿主机必须已经具备所需能力；不能仅凭“Windows 11”或版本号较高就承诺可用。

一般 Windows 支持矩阵也不能替代 MXC 检查：Windows 11 是推荐基线，近期完整更新的 Windows 10 属尽力支持；Win10 所需现代控制台能力与 MXC 可用性是不同条件。组织限制还可能使一个系统版本合适的设备无法使用某种实现。

“优先 MXC”与“强制 MXC”不同

消费者桌面端在设备支持时会自动优先 MXC。独立 CLI 或企业部署可在获准的 config.toml 中合并以下配置；已有 [features] 时只合并键，不重复声明表或覆盖整份配置：

[features]
prefer_mxc = true

这是偏好：设备或策略不支持时，仍进入既有旧版选择及初始化流程。管理员在 requirements.toml 中强制此 feature 值，也仍允许旧版回退。显式 windows.sandbox = "mxc" 则不同：不支持或被禁用时会失败。第 3 步用临时 CLI 参数测试，不改保存的选择。

公司电脑不能只看用户 config.toml

以下是供管理员核对的 requirements 示例，不是让读者自行写入以绕过策略：

[windows]
allow_mxc = false

这会阻止自动选择及显式选择 MXC。另一项常见限制是：

[windows]
allowed_sandbox_implementations = ["elevated"]

后者约束旧版实现，禁止回退到 unelevated；它本身不禁止 MXC。其他权限、网络要求仍然生效，不能从这一个键推导全部授权。

在实际 CLI 会话用 /status、/debug-config 核对有效会话与配置来源。Windows 系统要求文件可位于 %ProgramData% 下的 OpenAI\Codex\requirements.toml，但本地文件不是唯一来源：云端 Agent Security 等更高优先级来源也可能参与。旧 managed_config.toml 的启动默认值又有不同优先级，不能假设 -c 永远覆盖管理层。参见官方受管配置说明。

预期结果： 你能说清设备候选实现、组织允许范围及当前实际选择。配置来源不一致时先看config.toml 不生效排查，受管限制由管理员核对，不删除要求文件或改安全策略“试试看”。

3. MXC 启动探针：只验证当前命令启动

适用条件： 原生 Windows，实际 CLI 为 0.162.0 或更新版本，并允许在项目目录做此项检查。若组织不允许 :workspace 权限配置，停止使用这个示例，请管理员给出获准配置的验证方式。

从目标项目目录，在普通 PowerShell 中运行官方兼容性探针：

codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
$LASTEXITCODE

--include-managed-config 保留受管要求；:workspace 是权限配置，不是沙箱实现名称。紧接着读取 $LASTEXITCODE，避免被后续其他原生命令覆盖。

结果	可以得出的结论	下一步
输出 `MXC_OK`，退出码 `0`	当前 CLI 在这台设备、此配置和受管要求下成功启动了这条 MXC 命令	第 6 步验证访问范围，再检查正常任务
参数不存在或命令用法不支持	先检查真实 CLI 版本和该版本帮助	不把它当作设备不支持；先更新到组织批准、含该能力的版本
原生能力不可用、MXC 不受支持	当前设备未满足所需原生能力	核 OS build 与更新部署，由 IT 评估获准旧版回退
被要求文件、权限配置或网络策略拒绝	有效策略阻止了本次选择或执行条件	保留错误类别，由管理员核配置来源和适用范围
其他启动错误	还不能归因于 MXC 能力、1385 或路径权限中的某一种	收集第 7 步信息，按完整错误继续定位

成功不证明保存配置已切换 MXC、桌面端使用同一 CLI、项目所有路径可访问或网络符合预期；它也不是调用模型的端到端测试。旧版本不应直接照抄此探针并据失败判设备不兼容。0.162.0 是该探针的版本起点，不是所有受管字段或桌面端的统一最低版本；企业部署还需在实际客户端版本上验证所分发字段的支持与生效情况。

4. 旧版 sandbox setup failed：查初始化阶段

适用条件： 已确认 MXC 不可用或被禁用，且当前组织批准使用 legacy elevated。

获准的回退配置为：

[windows]
sandbox = "elevated"

已有 [windows] 时合并此键，保留其他设置。此处选择回退实现，不会使被组织禁止的实现变为可用，也不替代初始化。

查看错误是在 UAC／管理员批准、创建本地用户或组、防火墙配置，还是用户登录阶段。记录失败阶段，不只保留最后一行 setup failed。
如果只是拒绝了 UAC，且设备与组织允许初始化，可重新走 Codex 提供的 elevated setup 并批准。当前 CLI 的 /setup-default-sandbox 仅在 Windows 使用受限令牌的降级沙箱时出现；它不是每个版本、每种实现都有的命令。MXC 没有该入口不构成故障。
公司设备阻止本地用户／组创建、防火墙变更或沙箱用户登录权时，交由 IT 处理。IT 可按官方 Windows 部署流程使用可信 CLI，从适当提权的部署进程为目标员工身份及其 CODEX_HOME执行 provisioning；不要误用 SYSTEM 的用户目录。
初始化成功后，员工从普通终端重启 Codex，检查有效实现，让代理仅执行 cmd.exe /d /c echo LEGACY_OK。核对工具执行记录、LEGACY_OK 输出和退出码 0，不以模型口头回复替代结果。

预期结果： setup 完成，并且普通员工会话能真正启动沙箱命令。只安装了 CLI、弹出了管理员提示或创建了账户，都不算启动验收完成。elevated 指初始化需要管理员批准，不代表日常命令以管理员身份执行。

如果只能考虑 unelevated，先由管理员确认策略允许，并核对任务能否接受其较弱网络隔离及不支持拒绝读取路径的限制。无法满足要求时保留现场，评估获准的其他环境；不要默认切换 full access、关闭 private desktop、删除沙箱账户或整应用提权来消除提示。

5. Windows 错误 1385：查沙箱用户的登录权限

适用条件： 旧版沙箱启动命令报 1385，尤其是 setup 看似完成后，每条命令仍立即失败。

官方 FAQ说明：Windows 拒绝了沙箱用户启动命令所需的登录类型。通常账户已经创建，后续启动却被策略阻止；这与 MXC 原生能力缺失不同。

向 IT 提供错误文本、所选实现、失败时间、Windows build 和 CLI／客户端版本。
请 IT 核对 Codex 创建的沙箱用户是否具备所需登录权限；若只影响部分机器，比较生效的组策略、OU 和用户分配差异。
策略修正并生效后，重启对应客户端，在同一员工身份和工作目录执行固定标记命令，再做第 6 步访问验证。
仍失败时，提供脱敏后的 CODEX_HOME/.sandbox/sandbox.log 相关片段，保留错误号及阶段。不要发送 .sandbox-secrets/ 内容，也不需要提交完整配置或私人项目文件。

若业务急需临时回退，仍须满足第 4 步的组织允许和能力条件；不能因为是 1385 就无条件改为 unelevated。不要自行批量放开登录权、修改组策略或删除重建本地账户，反复 setup 也不保证改变有效域策略。

修复标准： 同一员工会话中的沙箱命令能启动，且后续边界检查符合预期；只在管理员终端成功，不足以证明员工环境恢复。

6. 启动成功以后，单独验证访问权限

文件验证：允许写入与只读拒绝分别检查

适用条件： MXC 启动探针已成功，CLI 版本符合第 3 步要求，组织同时允许 :workspace 与 :read-only，并允许在当前项目中新建一个无敏感测试目录。该目录不能放真实凭据或现有业务文件。

以下示例创建带随机名称的目录，只写固定文本，保留结果供检查；不修改 ACL 或现有配置。它显式测试 MXC 的两种权限配置，不会自动代表日常会话的自定义配置。

$checkDir = Join-Path (Get-Location).Path ("codex-sandbox-check-" + [guid]::NewGuid().ToString("N"))
New-Item -ItemType Directory -Path $checkDir -ErrorAction Stop | Out-Null
Push-Location -LiteralPath $checkDir
try {
    codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c "echo SANDBOX_WRITE_OK>allowed.txt"
    $writeExit = $LASTEXITCODE
    "workspace_exit=$writeExit"
    if (Test-Path -LiteralPath .\allowed.txt) { Get-Content -LiteralPath .\allowed.txt }

    codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :read-only -- cmd.exe /d /c "echo SHOULD_NOT_WRITE>denied.txt"
    $denyExit = $LASTEXITCODE
    "readonly_exit=$denyExit"
    "denied_file_exists=$(Test-Path -LiteralPath .\denied.txt)"
} finally {
    Pop-Location
}

预期第一条沙箱命令退出 0，allowed.txt 内容为 SANDBOX_WRITE_OK；第二条因写入被拒绝而非零退出，且 denied_file_exists=False。必须结合实际文件和错误原因看：参数解析失败、实现根本没启动或配置被禁止，也可能非零退出，但不算验证了只读边界。若第二条意外写出文件，停止扩大测试，保留无敏感结果并检查实际生效配置。

使用获准旧版实现时，可由 IT 在两处把 windows.sandbox=mxc 替换为实际实现，保留 managed 参数及权限配置再做同类检查；结果仅适用于实际测试的实现。若配置或版本不支持这些 profile，不能用去掉受管要求或换 full access 的方式追求通过。

最后回到正常任务会话，查看 /status、/debug-config，让代理仅在该测试目录执行一次固定文本写入和读取；核对工具记录、实际文件及内容，再运行项目必要检查。普通会话若按组织设计为只读，写入被拒绝本身就是预期结果，不应为“修复”而放宽它。

此测试不证明所有路径都受到正确限制。:workspace 还允许系统临时目录，不能推导“项目外全拒绝”；也不要用 .git、真实 .env 或凭据文件作为探针。Git 受保护路径写入失败需要按其独立边界处理。

网络验证：先核策略，再做获准目标的最小请求

MXC 的受管网络要求有效 allow_local_binding = true。同时它允许与宿主机 loopback 服务双向连接；代理域名规则对经代理流量仍生效，但代理额外的私有网络目标检查会移除。因此不能把旧版网络隔离假设直接套到 MXC，也不要为让探针通过自行全局打开此选项。由管理员先判断是否符合组织网络要求。

验证时先确认当前会话预期禁网还是允许特定目标。若允许，由管理员提供获准的无认证健康地址，在相同执行端、相同权限下做一次有超时限制的只读请求；核对状态、错误类别与代理记录，不发送 API Key、不读取私有响应正文。域名规则验证还需确认代理已启用：仅设置 profile 的 network.enabled = true 不会启动代理。

禁网任务访问失败可能完全正常；公共网页 HTTP 200 也不证明登录、私有 API 或所有目标可用。需要继续区分 DNS、代理、TLS 和命令联网时，使用终端能联网但 Codex 任务连不上指南。

还有两个容易漏掉的运行期边界

后台服务： MXC 的前台命令结束后，剩余子进程会停止。开发服务器刚输出 ready 不代表后续可访问；依赖 detached server 的流程要在前台命令结束后再检查服务是否仍在，不能只用 echo 验收。
拒绝读取的 glob： MXC 与旧版 elevated 在每个沙箱进程启动时枚举匹配文件；后来新建的匹配文件，在其他权限允许时仍可能被该进程读取。快照跟随进程生命周期，不是整个 Codex 会话。长驻 shell、watcher 和开发服务器需单独评估；不要用真实秘密验证，也不能把普通“只读”误解成“不可读”。相关行为见官方 deny-read 说明。

7. 重启后复查，并整理足够但不泄密的诊断信息

适用条件： 更新、仓库迁移、权限或组织策略变更后故障重现，或上述步骤仍不能定位。

先保存工作，重启对应客户端，再确认工作目录与有效配置。MXC 重新做第 3 步探针；获准的旧版 elevated 才检查对应 setup。若出现 Everyone 可写目录警告，记录 Codex 列出的路径，请目录负责人或 IT 核对是否权限过宽；不要对整个磁盘递归改 ACL。

求助时整理以下信息，使用脱敏路径和短日志片段：

信息	需要回答的问题
客户端与真实执行端	桌面端／CLI／IDE？Windows 原生还是 WSL？普通用户还是部署进程？
系统与程序版本	Windows 版本、完整 build、CLI 和客户端版本，来自哪个批准的安装源？
实现及有效策略	实际是 mxc／elevated／unelevated？是否允许 MXC、旧版回退与所测 profile？
错误阶段与结果	初始化还是命令启动？是否 1385？标记、退出码、文件存在状态各是什么？
最近变化与日志	是否搬过仓库、更新过系统／客户端／策略？失败时间附近 sandbox.log 有什么错误？

仅分享必要的脱敏 CODEX_HOME/.sandbox/sandbox.log 片段；不要包含 .sandbox-secrets/、认证文件、完整环境变量或私人源码。模型说“沙箱已修好”不能替代命令、退出码和实际文件结果。

如果原生实现不满足需求，可以评估组织批准的 WSL2 环境；这是执行环境选择，需要重新核对工具、配置和目录。当前文档注明 WSL1 仅支持至 Codex 0.114，0.115 起 Linux 沙箱转为 bubblewrap 后不再支持 WSL1。不要把改用 WSL 当作所有 setup 或 1385 故障的统一修复。

完成排查应留下两份结论：哪种获准实现、在哪个设备和客户端成功启动；正常任务在什么有效权限下，通过了哪些访问检查。 未验证的路径、网络、后台进程和其他客户端继续标为未验证。