Codex Windows 沙箱报错 1385：沙箱用户建好了，命令却跑不起来

2026-08-09

在 Windows 上装 Codex（OpenAI Codex）的命令行工具，最容易卡住人的不是登录，也不是配置文件，而是沙箱。装完看着一切正常，Codex 也提示沙箱初始化完成了，结果真要执行一条命令时，蹦出来一个 1385。

这个号码本身没什么可读性，但它指向的问题其实相当具体。下面按「现象 → 判定 → 处置 → 验证 → 排除」的顺序走一遍，中间凡是我本机跑过的，我都会标出版本和环境；凡是我没跑过、只有官方文档口径的，我也会明说。

一、1385 到底在说什么

官方文档在《Windows sandbox》的已知问题里，对错误 1385 的原话是：

“Windows is denying the logon type the sandbox user needs.”

翻成人话：沙箱用户已经建出来了，但系统策略不允许这个用户以 Codex 需要的方式登录、进而执行命令。

这句话有两个信息量很大的点，很多人第一遍会读漏：

第一，这不是”沙箱没装上”。用户已经创建成功了，说明前半段初始化是走通的。所以你去反复卸载重装 Codex、反复删目录重来，大概率原地打转——问题不在安装环节，在这个已存在的账户能不能登录。

第二，这是 Windows 侧的策略在拒绝，不是 Codex 在拒绝。Codex 只是那个被拒绝之后把错误码抛给你的角色。

要理解为什么会牵扯出一个”沙箱用户”，得先看 Codex 在 Windows 上的沙箱是怎么实现的。

二、先分清平台：Windows 这套跟 Linux 完全不是一回事

这是排错的分水岭，先说清楚能省掉大量无用功。官方文档对三个平台的沙箱实现讲得很明确：

平台	沙箱实现
macOS	系统内置的 Seatbelt 框架
Windows	在 PowerShell 中使用原生 Windows 沙箱
Linux / WSL2	需要用包管理器安装 `bubblewrap`（bwrap）

看到没有，Linux 上”沙箱起不来”第一件事是查 bwrap 装没装；Windows 上压根不存在这个包，把 Linux 的排查步骤套到 Windows 上是纯粹浪费时间。反过来，如果你是在 WSL2 里跑 Codex，那用的是 Linux 沙箱实现，本文这一套 Windows 受限 token 的排查也不适用于你。

Windows 原生沙箱的定位，官方写的是在 PowerShell 中原生运行，强制”bounded filesystem and network permissions”，不需要 WSL、也不需要虚拟机。它有两种模式：

模式	官方描述的特征
`elevated`（官方标注为首选）	使用专用的低权限沙箱用户；文件系统权限边界 + 防火墙规则；需要管理员批准的初始化设置
`unelevated`（回退）	用”从当前用户派生的受限 Windows token”运行命令；基于 ACL 的文件系统边界；用环境级离线控制替代防火墙规则；保护更弱，但在拿不到管理员批准时可用

1385 里那个”沙箱用户”，对应的正是 elevated 模式里那个专用的低权限账户。这也解释了为什么这个错在 elevated 路径上出现——unelevated 走的是从你当前用户派生的受限 token，不新建独立账户，自然也就没有”这个新账户能不能登录”的问题。

顺带说一句，官方对 unelevated 自己写的就是”保护更弱”。所以后面提到回退时，我不会把它包装成”同样安全的替代方案”，它就是个在拿不到管理员权限时的降级选择。

三、怎么确认自己撞的就是这个问题

别凭印象判断，跑几条命令，几十秒就能定位。以下几条我在 codex-cli 0.147.0（Windows 11）上都实际执行过，前三步是纯只读的，第四步是往仓库里写一个测试文件（实测在沙箱里并没有落盘，见第五节），都不会动你现有的东西。

第一步，先确认版本。

codex --version

这条不是走过场。我在同一台机器上采集数据时，开头执行 codex --version 拿到的是 codex-cli 0.131.0，十几分钟后再执行同一条命令就变成了 codex-cli 0.147.0，而 which -a codex 全程只有一个可执行文件。Codex 具备自更新能力，所以排查任何跟版本行为相关的问题，都必须以当次实时输出为准，不能用你记忆里的版本号。你在论坛上看到的”某版本有这个 bug”，先对一下自己现在到底是哪个版本。

第二步，看 doctor 怎么说沙箱。

codex doctor --summary

在 codex-cli 0.147.0（Windows 11）上，这条命令的输出会分成 Notes / Environment / Configuration / Updates / Connectivity / Background Server 几组，其中 Configuration 组里有一行 sandbox。我本机这行显示的是：

sandbox    restricted fs + restricted network · approval OnRequest

这是沙箱正常工作时的样子——文件系统受限、网络受限、审批策略是 OnRequest。如果你这一行的状态符号不是 ✓，那沙箱侧确实有事。输出结尾还有一行统计，格式类似 17 ok · 1 idle · 1 notes · 0 warn · 0 fail，扫一眼就知道有没有 fail。

顺便说个我实测出来的、很多人会栽的点：配置文件坏掉时 doctor 照样能跑完，但会在结果里明确告诉你配置没加载成功。我故意用 codex -c 'features=[unclosed' doctor --summary 传了一段语法不合法的 TOML，命令没崩，doctor 正常跑完，只是多出一行：

✗ config       config could not be loaded - Fix the reported config error, then rerun codex doctor.

所以「我明明改了配置怎么没生效」的第一步永远是跑 doctor 看这一行。这条对 1385 的排查也有用——你以为自己已经把沙箱模式改成 unelevated 了，实际上整个配置文件根本没被加载。

第三步，确认你当前用的是哪种 Windows 沙箱模式。

模式由配置键 windows.sandbox 控制，取值是 "elevated" 或 "unelevated"。在 codex-cli 0.147.0（Windows 11）上，我本机 ~/.codex/config.toml 里就是：

[windows]
sandbox = "elevated"

与之相关的还有一个键 windows.sandbox_private_desktop，默认值是 true。

第四步，直接拿沙箱跑一条无害命令。

codex sandbox cmd /c "echo hi > <某个仓库路径>\__sbtest.txt"

这条就是我在 codex-cli 0.147.0（Windows 11）上实际跑过的那条，把 <某个仓库路径> 换成你自己的仓库目录即可。codex sandbox 这个子命令的官方说明就是 “Run commands within a Codex-provided sandbox”，位置参数的说明写得更直白：“Full command args to run under Windows restricted token sandbox”。用它试一条 echo 这种绝对无害的命令，是把「沙箱能不能起来」跟「模型能不能干活」彻底解耦的最快办法——如果这一步就报 1385，基本可以把问题收敛到沙箱层，与提示词、模型侧先脱钩。它返回之后那个文件在不在，第五节还会当成验证手段再用一次。

第五步，去看沙箱自己的日志。 官方指明日志位置是 CODEX_HOME/.sandbox/sandbox.log。在 codex-cli 0.147.0（Windows 11）上，我确认 ~/.codex/ 目录下确实存在 .sandbox/、.sandbox-bin/、.sandbox-secrets/ 这三个目录，路径是对得上的。

四、官方给的处置：四步，按顺序来

先把话说在前头：关于 1385，官方文档给出的处置只有下面这四步。 网上流传的那些改注册表、调组策略、手工给某个本地用户授予某种登录权限的写法，不在官方文档里，我也没有在本机复现并验证过 1385（我本机的沙箱是正常的），所以这篇一个字都不会写。改这类系统策略是有真实副作用的，不能靠推断。

官方的排查顺序是：

① 重启 Codex。 别跳过。官方把重启列为第一步，成本最低，先照做——至于它为什么排在第一位、内部发生了什么，官方文档没解释，这里也不替它编一套机制。

② 重试 elevated 初始化。 elevated 是官方标注的首选模式，值得再试一次。这里要特别留意——官方列出的初始化失败常见原因有三条：拒绝了 UAC 提示、本地用户创建被阻止、防火墙规则被限制。对照 1385 的含义（用户建好了但不让登录）看，第二条”本地用户创建被阻止”往往表现为更早的失败；而 1385 更像是账户这一环过了、登录这一环被策略挡住。重试时 UAC 弹窗一定要点允许，弹窗一闪而过没看清就重来一次。

另外，Windows 沙箱有个硬性要求：winget 必须可用。这条在支持条件里写得很清楚，如果你的机器上 winget 被裁掉或不可用，先解决它。

③ 需要时回退到 unelevated。 这是拿不到管理员批准时的降级路径。配置写法是：

[windows]
sandbox = "unelevated"

也可以用命令行的 -c 覆盖来临时试一次，-c 的规则是用点号路径表示嵌套、值按 TOML 解析、解析失败则按字面字符串处理：

codex -c windows.sandbox="unelevated" doctor --summary

以上为按官方文档键位组合的示例，未逐项实测，以官方文档为准。

回退之前请想清楚代价：unelevated 不新建专用沙箱用户，而是用从你当前用户派生的受限 token，文件系统边界靠 ACL，防火墙规则被换成环境级的离线控制——官方明写它保护更弱。如果这台机器上有你不想让 agent 碰的东西，这个取舍要你自己认。

④ 发送诊断。 日志在 CODEX_HOME/.sandbox/sandbox.log。如果你要把诊断信息发出去，codex doctor --json 是个更省心的选择，它的官方说明是 “Emit a redacted machine-readable report”，也就是脱敏的机器可读报告，贴给别人之前不用逐行去抹路径。

顺带补一句关于隐私的一手观察：在 codex-cli 0.147.0 上，codex mcp list 的 Env 列会把环境变量值打成 *****，只显示键名。这类自带脱敏的输出，贴到 issue 里比手工截图安全得多。但 sandbox.log 是原始日志，官方没有说它是脱敏的，发之前自己扫一遍。

还有一个跟权限相关、容易被忽略的提示：如果某个目录是”writable by Everyone”（对所有人可写），Codex 会告警，提示 Windows 权限过宽。看到这类告警不要当噪音关掉，它说明你的目录 ACL 确实松了，跟沙箱边界能不能立住直接相关。

五、处置完怎么验证沙箱真的活了

改完别急着去跑正事，用两条只读检查确认一下，否则你只是把问题推迟到了下一次。

验证一：doctor 的 sandbox 行恢复正常。

codex doctor --summary

对照本机在 codex-cli 0.147.0（Windows 11）上的正常形态：restricted fs + restricted network · approval OnRequest，状态符号是 ✓。同时看一眼结尾统计里 fail 是不是 0。

验证二：沙箱确实在拦东西，而不只是”没报错”。 这一步比第一步重要。沙箱不报错不等于沙箱在生效，得看它有没有真的挡住写操作。我在 codex-cli 0.147.0（Windows 11）上做过这么一次实测：在沙箱里执行 cmd /c "echo hi > <某个仓库路径>\__sbtest.txt"，命令返回之后，目标文件并不存在（ls 报 No such file or directory）。也就是说默认沙箱状态下对该路径的写入没有落盘。

这条实测结论在验证阶段的价值是：如果你照着做，文件真的写进去了，那说明沙箱边界没立起来，哪怕命令没报 1385，也别当作修好了。反过来，文件写不进去、命令又正常返回，才是沙箱在正常工作的样子——这个行为第一次见会以为是命令失败了，其实是设计如此。

六、什么情况说明不是 1385 这个原因

排查最怕方向错了还在使劲。下面几种情况看着都像”沙箱有问题”，但根子不在 1385 上，别往这个方向修。

情况一：报错文案里根本没有 1385，而是命令行参数报错。 比如沙箱模式的取值写错了。在 codex-cli 0.147.0（Windows 11）上执行 codex -s bogus-mode，得到的是：

error: invalid value 'bogus-mode' for '--sandbox <SANDBOX_MODE>'
  [possible values: read-only, workspace-write, danger-full-access]

这就是纯粹的取值拼错，-s / --sandbox 只认 read-only、workspace-write、danger-full-access 三个值，跟 windows.sandbox 那个 elevated / unelevated 不是同一个维度——前者管的是 agent 有多大权限，后者管的是 Windows 上沙箱怎么实现。这两个概念撞车是我见过最多的误会来源。

情况二：doctor 里出现 config could not be loaded。 那是配置文件语法坏了，整个配置压根没加载，你对 windows.sandbox 做的任何修改都不会生效。先修配置，再谈沙箱。

情况三：你其实是在 WSL2 里跑。 那走的是 Linux 沙箱实现，要查的是 bubblewrap 装没装，本文这套 Windows 受限 token 的排查完全不适用。

情况四：报的是 --sandbox-state-* 相关的参数缺失。 在 codex-cli 0.147.0（Windows 11）上，我单独给 --sandbox-state-disable-network 而不给 --sandbox-state-json，直接报：

error: the following required arguments were not provided:
  --sandbox-state-json <JSON>

这几个 --sandbox-state-* 选项是一组的，必须先有 state JSON 才能在其上做增删。这是用法问题，不是沙箱坏了。

情况五：命令跑完了，只是没出网。 官方明说某些任务会故意在无出网的状态下运行，取决于权限模式。没网不等于沙箱故障，反而可能正是它在按设计工作。

最后一个前提性的排除项：Windows 版本。 官方给的支持矩阵是 Windows 11 推荐、较新的 Windows 10（v1809+）尽力而为（best effort）、更老的 Windows 10 不推荐。如果你在一台很老的 Windows 10 上死磕沙箱初始化，那大概率不是配置能救回来的，先确认自己在不在支持范围里。