拿不到管理员权限：Codex Windows 沙箱 unelevated 回退模式的取舍

2026-08-09

在公司发的 Windows 电脑上装 Codex（OpenAI Codex）的 CLI，最容易撞上的不是模型问题，是权限问题。装好之后想跑起来沙箱，弹出 UAC 提示，你点了也没用——因为帐户压根没在管理员组里；或者干脆连提示都没弹，IT 的策略把本地用户创建给禁了。这时候 Codex 的沙箱要么起不来，要么状态跟你预期的不一样。

Codex 在 Windows 上给了一条退路，叫 unelevated 模式。这篇就把「确认是不是这个坑 → 官方给的处置 → 回退之后怎么验证 → 什么情况说明你找错方向了」走一遍。先说清楚边界：本文所有实测结论都来自 codex-cli 0.147.0（Windows 11）上的只读命令输出，我们没有发起过任何模型对话请求；官方口径部分来自 Codex 官方文档。

一、现象长什么样

官方在 Windows 沙箱这一页里列出的初始化失败常见原因有三条，正好对应了普通员工机上最常见的三种处境：

拒绝了 UAC 提示（包括你想批但批不了）；
本地用户创建被阻止；
防火墙规则被限制。

还有一个有具体编号的错误值得单拎出来：错误 1385。官方原文是 “Windows is denying the logon type the sandbox user needs.”，意思是沙箱用户其实已经建出来了，但系统策略不允许它以所需的登录类型去执行命令。这一条的迷惑性在于——你会觉得「用户都建好了，应该没问题了吧」，实际上卡在了后面一步。

另外有两个现象不算故障，但很多人会误判成故障：一是某些任务会故意在没有出网的状态下运行，具体取决于权限模式；二是如果某个目录是「对所有人可写」（writable by Everyone）的，Codex 会给出告警，提示 Windows 权限过宽。这两条都是设计如此，不是初始化失败。

二、怎么确认真的是这个问题

别急着改配置，先跑三条只读命令，把当前状态钉死。

第一条，看版本。

codex --version

这条不是走过场。本机采集时有一个实打实的观察：同一台机器上，先执行得到 codex-cli 0.131.0，十几分钟后再执行同一命令得到 codex-cli 0.147.0，而 which -a codex 全程只有一个可执行文件。Codex 具备自更新能力（配置里 check_for_update_on_startup 默认为 true），所以「我昨天看到的版本号」不能当依据。排查任何跟沙箱、特性阶段有关的问题，都得以当次输出为准。

第二条，看诊断。

codex doctor --summary

在 codex-cli 0.147.0（Windows 11）上，这条命令的输出按 Notes / Environment / Configuration / Updates / Connectivity / Background Server 分组，你要盯的是 Configuration 组里的 sandbox 行。本机这一行显示的是 restricted fs + restricted network · approval OnRequest，即「文件系统受限 + 网络受限，审批策略为 OnRequest」。如果这行跟你的预期对不上，那问题就在沙箱这一侧，可以往下走；如果对得上，那说明沙箱是起来的，你遇到的多半是别的事。

输出结尾会有一行统计，格式像 17 ok · 1 idle · 1 notes · 0 warn · 0 fail ok，并提示可以用 --all 展开被截断的列表。状态符号有四种：✓（ok）、○（idle）、⚠（notes/warn）、✗（fail）。

第三条，看沙箱日志的位置。 官方明确给出沙箱日志路径是 CODEX_HOME/.sandbox/sandbox.log。本机实测 ~/.codex/ 下确实存在 .sandbox/、.sandbox-bin/、.sandbox-secrets/ 三个目录。所以要交诊断材料的时候，知道去哪儿捞日志，比截一堆屏有用得多。

顺带一个硬性前提：官方把 winget 必须可用列为 Windows 沙箱的要求。如果这台机器上 winget 被卸了或者被策略禁了，先解决这个，不然后面折腾都是白折腾。

三、官方给的处置顺序

Windows 沙箱页给的排查顺序是四步，照这个顺序来，别跳步：

重启 Codex；
重试 elevated 初始化；
需要时回退到 unelevated；
发送诊断，日志在 CODEX_HOME/.sandbox/sandbox.log。

第 3 步就是本文的主角。官方把两种模式的差别写得很清楚：

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

请注意最后四个字是官方自己写的：保护更弱。所以这不是「两个平级选项挑一个」，而是「首选方案用不了时的降级方案」。我在这儿不会替它打包票说 unelevated 有多安全，官方都没这么说。

配置键在 ~/.codex/config.toml 里：

[windows]
sandbox = "unelevated"
sandbox_private_desktop = true

windows.sandbox 的取值只有 unelevated 和 elevated 两个。windows.sandbox_private_desktop 默认就是 true，含义是默认在私有桌面上运行沙箱子进程——上面这段把它显式写出来只是为了让你知道有这么个键，不写也是这个值。以上为按官方文档键位组合的示例，未逐项实测，以官方文档为准。

如果你不想动配置文件，只想临时试一次，可以用顶层的 -c 覆盖。-c 的官方说明是：覆盖 ~/.codex/config.toml 里的值，点号路径表示嵌套（foo.bar.baz），value 按 TOML 解析、解析失败则按字面字符串处理。官方给的例子之一是 -c shell_environment_policy.inherit=all，所以 windows.sandbox 这种两级键同样走点号写法。

顺便提醒一个容易踩空的地方：-c 写错键名不一定会立刻炸给你看。在 codex-cli 0.147.0（Windows 11）上实测，codex -c model_reasoning_effortt=high --strict-config exec --help 会正常打印 help，并没有报未知字段错误——说明 --strict-config 的校验发生在真正加载配置去跑会话的时候，--help 这类不进入会话的路径不触发校验。所以别用 --help 去「验证」你的键名拼对了。

四、回退之后怎么验证

改完不能只看它「没报错」，得看边界还在不在。

第一，回到 doctor。 再跑一次 codex doctor --summary，重点仍然是 Configuration 组的 config 行和 sandbox 行。这里有条实测结论特别值钱：在 codex-cli 0.147.0（Windows 11）上，故意用 codex -c 'features=[unclosed' doctor --summary 传一段语法不合法的 TOML，命令没有崩溃退出，doctor 照常跑完，但 Notes 区出现了这么一行：

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

翻译成人话：**配置写坏了，Codex 不会拦着你，它只是不加载而已。**所以「我明明改成 unelevated 了怎么没生效」的第一嫌疑人，永远是这一行。

第二，用 codex sandbox 跑一条无害命令，亲眼确认写入被挡住。 这个子命令的官方说明是 “Run commands within a Codex-provided sandbox”，位置参数的说明写得更直白：Full command args to run under Windows restricted token sandbox。在 codex-cli 0.147.0（Windows 11）上，我们在沙箱里执行了一条往仓库路径写文件的命令：

codex sandbox cmd /c "echo hi > <你的仓库目录>\__sbtest.txt"

命令返回之后，那个文件并不存在（ls 直接报 No such file or directory）。这就是最省事的一次性验证：写一个你不在乎的临时文件，回头看它在不在。在不在，比任何配置读数都实在。

第三，别在这条命令上乱加参数。 同样是实测：单独给 --sandbox-state-disable-network 而不给 --sandbox-state-json，会直接报参数缺失：

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

也就是说 --sandbox-state-* 这几个选项是一组的，必须先有 state JSON 才能在其上做增删。别把它当成「一键断网开关」来用。

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

这一节是为了防止你在 unelevated 这条路上一条道走到黑。

你根本不在 Windows 原生沙箱这条路上。 官方的分平台实现是三套东西：macOS 用系统内置的 Seatbelt 框架；Windows 在 PowerShell 中使用原生 Windows 沙箱；而在 WSL2 里走的是 Linux 沙箱实现，Linux/WSL2 需要用包管理器装 bubblewrap（bwrap）。所以如果你的 Codex 实际跑在 WSL2 里，「沙箱起不来」第一件事是查 bwrap 装没装，windows.sandbox 改成什么都不相干。不要把 Linux 的排查步骤套到 Windows 上，反过来也一样。

你的系统版本本来就不在推荐范围。 官方给的支持程度是：Windows 11 推荐；较新的 Windows 10（v1809+）为尽力而为（best effort）；更老的 Windows 10 不推荐。落在后两档时，反复重试 elevated 初始化的性价比很低。

你混淆了「审批」和「沙箱」。 这是最常见的一类误判。审批策略 approval_policy 有三档：untrusted（只有受信任命令如 ls、cat、sed 免审批，其余升级给用户）、on-request（由模型决定何时请求审批）、never（从不询问，执行失败直接回传给模型）。关键在于——never 不等于「放开权限」，沙箱边界还在，它改变的只是「要不要问你」。真正撤掉边界的是沙箱模式里的 danger-full-access，或者那个官方原文写着 “EXTREMELY DANGEROUS” 的 --dangerously-bypass-approvals-and-sandbox。如果你想解决的其实是「老弹审批框」，那该动的是 approval_policy，跟 elevated/unelevated 一点关系都没有。

你遇到的是登录问题。 沙箱起不来和没登录，表现出来都可能是「跑不动」。跑一条 codex login status 就能分开，本机这条命令的输出是一行 Logged in using ChatGPT。

你遇到的是出网被挡。 前面说过，某些任务会故意在无出网状态下运行，这取决于权限模式；而 workspace-write 下是否出网由 sandbox_workspace_write.network_access 控制。这是另一条排查线，不要跟 elevated/unelevated 混在一起查。

最后，如果四步走完还是不行，官方给的终点是「发送诊断」。这里有个能让你少纠结的实测依据：codex doctor --json 的官方说明是 “Emit a redacted machine-readable report”——它是脱敏的。所以要往 issue 里贴诊断结果，用这个输出比手动截图靠谱。