Windows 上的 Codex 分层沙箱策略：可信项目用 unelevated，未知项目用 elevated
本文由 AI 辅助整理，并由作者人工核对和审阅。文中的实际行为可能随 Codex 版本和 Windows 环境变化，请在本机验证后应用。
资料核对：使用openai-docs技能查阅当前 Codex 官方手册。
问题背景
在 Windows 上使用 Codex 运行 pytest、uv、npm 等工具时，工具经常会创建缓存目录，例如：
.pytest_cache
.uv-cache
node_modules/.cache
当 Codex 使用 elevated Windows 沙箱时，命令会由专用低权限账户运行。部分工具创建的目录可能出现以下 ACL：
Owner : <machine>\CodexSandboxOffline
Access : OWNER RIGHTS Allow FullControl
NT AUTHORITY\SYSTEM Allow FullControl
BUILTIN\Administrators Allow FullControl
如果该目录同时关闭了权限继承，当前 Windows 用户可能无法在普通终端中访问，只能通过管理员权限或 Codex 沙箱账户操作。
这种权限割裂尤其影响缓存、测试输出和构建产物。
Auto 权限模式与 Windows 沙箱实现
Codex 的权限模式和 Windows 沙箱实现属于两个不同层级。
| 配置 | 控制内容 |
|---|---|
Auto |
Codex可以在哪些目录写入，以及何时请求授权 |
workspace-write |
文件系统的可写范围 |
elevated |
使用专用低权限 Windows 账户执行命令 |
unelevated |
使用从当前 Windows 用户派生的受限令牌执行命令 |
Auto 通常对应：
sandbox_mode = workspace-write
approval_policy = on-request
因此，将 Windows 沙箱改成 unelevated 后，仍然可以继续使用 Auto。工作区外写入依然需要授权，主要变化是底层命令执行身份。
elevated 与 unelevated 的区别
elevated
elevated 是官方推荐的高强度 Windows 沙箱，主要使用：
- 专用低权限沙箱账户
- 文件系统 ACL 边界
- 专用防火墙规则
- Windows 本地安全策略
它提供更强的身份隔离，适合运行来源不明的仓库、安装脚本和构建工具。
代价是沙箱账户创建的文件可能归属于 CodexSandboxOffline。如果新目录没有正确继承父目录权限，普通用户会遇到访问问题。
unelevated
unelevated 使用从当前 Windows 用户派生的受限令牌，并继续通过 ACL 限制文件系统范围。
主要优点包括：
- 新建文件通常归属于当前 Windows 用户
- uv、npm、pytest 等缓存更容易与本机工具共享
- 减少沙箱账户登录权限和 ACL 兼容问题
- 不需要依赖专用账户的防火墙规则
它的身份隔离和网络隔离强度低于 elevated，更适合可信的日常开发项目。
推荐方案
比较实用的策略是：
- 日常可信项目全局使用
unelevated - 来源不明的项目单独使用
elevated - 权限模式继续保持
Auto
全局默认使用 unelevated
编辑用户配置文件：
~/.codex/config.toml
加入：
[windows]
sandbox = "unelevated"
修改后需要完全重启 Codex CLI、IDE 扩展或 ChatGPT 桌面应用。
Codex CLI、IDE 扩展和桌面应用共享配置层级，因此用户级配置会影响本机上的多个 Codex 客户端。
为单个未知项目启用 elevated
一次性命令行覆盖
对于偶尔检查的未知项目，可以使用命令行覆盖：
codex --cd "D:\repos\unknown-project" -c 'windows.sandbox="elevated"'
命令行覆盖具有最高优先级，适合安全审查、依赖安装和首次构建。
创建 elevated profile
如果经常需要检查未知项目，可以创建：
~/.codex/elevated.config.toml
内容如下：
[windows]
sandbox = "elevated"
启动未知项目时使用：
codex --profile elevated --cd "D:\repos\unknown-project"
这样可以保留全局 unelevated，并通过显式 profile 为高风险项目恢复更强的隔离。
为什么不建议依赖项目内配置
可信项目可以在仓库中添加：
<repo>\.codex\config.toml
例如：
[windows]
sandbox = "elevated"
不过，Codex 只会在项目被标记为可信后加载项目级 .codex 配置。
信任项目还可能启用该仓库提供的：
.codex/config.toml- hooks
- rules
- 其他项目级 Codex 配置
对于真正来源不明的项目，不宜把仓库自身的配置当作安全边界。用户控制的命令行参数或 profile 更可靠。
Codex 配置优先级为：
- CLI 参数和
--config覆盖 - 可信项目中的
.codex/config.toml --profile选择的配置- 用户级
~/.codex/config.toml - 系统配置
- 内置默认值
安全性与便利性的取舍
| 场景 | 推荐配置 |
|---|---|
| 自己维护的项目 | unelevated + Auto |
| 公司内部可信仓库 | unelevated + Auto |
| 来源不明的开源项目 | elevated + Auto |
| 需要运行未知 npm 安装脚本 | elevated + Auto |
| 只阅读未知代码 | elevated + read-only |
| 完全可信且需要系统级操作 | 按操作逐次授权 |
danger-full-access 会进一步放宽文件系统和命令限制。普通开发工作一般不需要使用它。
验证配置是否生效
启动新的 Codex 会话并生成一个测试目录，然后在普通 PowerShell 中检查：
Get-Acl .\test-directory | Format-List Owner,AreAccessRulesProtected,Access
使用 unelevated 时，应重点确认：
- Owner 是当前 Windows 用户
AreAccessRulesProtected为False，或者 ACL 明确包含当前用户- 普通终端可以创建、修改和删除目录内容
使用 elevated 时，Owner 可能是：
CodexSandboxOffline
这属于专用沙箱账户模型的一部分。需要关注目录是否继承了允许当前用户访问的 ACL。
现有目录不会自动修复
修改沙箱模式只影响后续启动的 Codex 会话。此前由沙箱账户创建的目录不会自动更改所有者或恢复权限继承。
对于 .pytest_cache、临时 npm cache 等可丢弃内容，通常可以在确认路径后通过管理员终端删除。需要保留的产物应先备份，再恢复父目录权限继承或重新设置 ACL。
不要对整个磁盘或用户目录递归重置 ACL。权限修复应限定到明确的项目目录或缓存目录。
总结
Windows 上兼顾开发体验和安全性的配置可以概括为：
可信项目：unelevated + Auto
未知项目：elevated + Auto
只读审查：elevated + read-only
Auto 负责工作区范围和授权流程，elevated/unelevated 负责 Windows 底层执行身份。将两者分层配置，可以减少日常项目的权限割裂，同时为未知代码保留更强隔离。
浙公网安备 33010602011771号