Codex 在 Windows 下的沙箱边界与用户权限隔离逻辑

AI-assisted and human-reviewed disclosure: 本文由 AI 辅助整理，实验命令、结论和措辞经人工复核。

背景

在 Windows 上使用 Codex 处理本地项目时，我遇到一个现象：同一个项目目录下，有些文件归当前 Windows 用户所有，有些目录归 CodexSandboxOffline 所有。与此同时，git status 可以正常执行，但 git add 这类 Git 写操作会失败，除非经过 Codex 的审批/提权流程。

这篇文章记录一次实测过程，目标是回答三个问题：

1. Codex 未经我批准执行命令时，到底使用哪个 Windows 用户？
2. 我批准后执行命令时，又使用哪个 Windows 用户？
3. 什么情况下需要提权，尤其是 Git 命令？

实验日期：2026-07-05。
本机 Codex 版本：codex-cli 0.142.5

官方文档依据

OpenAI Codex 文档里有两个关键点：

• Sandbox 会作用于 Codex 启动的本地命令，包括 git、包管理器、测试 runner 等。
• Windows 的 elevated sandbox 会使用 dedicated lower-privilege sandbox users，并通过文件系统边界、防火墙规则等机制限制命令。

参考：

• https://developers.openai.com/codex/concepts/sandboxing
• https://developers.openai.com/codex/windows

换句话说，在 Windows 上，Codex 的 shell 命令不一定以当前登录用户运行。

一个更简单的二分模型

实际使用时，可以先不用纠结术语，把 Codex 操作分成两类：

类型	含义
未经审批执行	Agent 可以直接运行的操作
审批后执行	Agent 请求权限，你同意后才运行的操作

这次实验表明，在我的环境里：

未经审批的 shell 命令 = CodexSandboxOffline
审批后的 shell 命令 = 当前 Windows 用户

实验一：未经审批时的执行身份

命令：

C:\Windows\System32\whoami.exe

输出：

<HOST>\codexsandboxoffline

进一步查看 SID：

C:\Windows\System32\whoami.exe /user

输出：

User Name                    SID
<HOST>\codexsandboxoffline   S-...-1004

结论：Codex 未经审批执行 shell 命令时，使用的是 CodexSandboxOffline 这个低权限沙箱用户。

实验二：未经审批创建文件

命令：

$dir = 'D:\...\tmp\identity-test'
New-Item -ItemType Directory -Force -Path $dir | Out-Null
$file = Join-Path $dir 'unapproved-shell-ps.txt'
Set-Content -LiteralPath $file -Value 'created by unapproved powershell shell command'
(Get-Acl -LiteralPath $file).Owner

输出：

<HOST>\CodexSandboxOffline

再用 cmd 做一次：

cmd /c "whoami && echo created > tmp\identity-test\unapproved-shell-cmd.txt"
(Get-Acl -LiteralPath 'D:\...\tmp\identity-test\unapproved-shell-cmd.txt').Owner

输出：

CodexSandboxOffline
<HOST>\CodexSandboxOffline

结论：未经审批的 shell 命令，无论是 PowerShell 还是 cmd，创建出来的文件 owner 都是 CodexSandboxOffline。

实验三：审批后执行身份

同样运行：

C:\Windows\System32\whoami.exe

但这次通过 Codex 的 require_escalated 审批流程执行。

输出：

<HOST>\<current-user>

在我的环境里，实际用户是当前 Windows 登录用户。

实验四：审批后创建文件

命令：

$dir = 'D:\...\tmp\identity-test'
New-Item -ItemType Directory -Force -Path $dir | Out-Null
$file = Join-Path $dir 'approved-shell-ps.txt'
Set-Content -LiteralPath $file -Value 'created by approved powershell shell command'
(Get-Acl -LiteralPath $file).Owner

审批后输出：

<HOST>\<current-user>

结论：审批后执行的 shell 命令以当前 Windows 用户身份运行，创建的文件 owner 也是当前用户。

Git 为什么更容易触发提权

项目里 Git 仓库初始化后，普通读取命令可以直接运行：

git status --short

但这个命令失败：

git add --dry-run .

错误：

fatal: Unable to create 'D:/.../.git/index.lock': Permission denied

注意：即使是 --dry-run，Git 仍会尝试创建 .git/index.lock。这说明它已经越过了“只读查看”的边界，开始触碰 Git 元数据写入。

审批后，同一个命令成功：

add '.gitattributes'
add '.gitignore'
add 'AGENTS.md'
...

结论：

Git 命令类型	是否需要提权
git status	不需要
git diff	通常不需要
git log	不需要
git rev-parse	不需要
git add	需要
git commit	需要
git lfs install --local	需要
修改 hooks / config / index	需要

判断标准很简单：只读 Git 命令一般不需要提权；会写 .git/ 的命令需要提权。

为什么会出现混合 owner

Windows 的 NTFS owner 是逐文件、逐目录记录的。谁创建了对象，通常谁就是 owner。

因此项目里可能出现这种混合状态：

普通项目文件             <current-user>
Codex 未审批创建的 tmp/   CodexSandboxOffline
审批后创建的 .git/        <current-user>

这不是 Git 的特殊行为，而是 Windows 文件 owner 与 Codex sandbox 执行身份叠加后的结果。

safe.directory 只是解决 Git 信任问题

如果 Git 发现仓库目录 owner 和当前运行 Git 的用户不一致，可能报：

fatal: detected dubious ownership in repository

可以用：

git config --global --add safe.directory D:/.../仓库目录

这只解决 Git 是否信任这个目录的问题。它不会让 Codex 沙箱获得 .git/ 写权限，也不会改变 shell 命令的执行用户。

所以：

safe.directory 解决 Git 信任
Codex approval 解决越过 sandbox 边界
NTFS ACL/owner 决定文件实际归属

实用结论

在当前 Windows Codex 环境下，可以按下面的规则工作：

1. Codex 未经审批的 shell 命令会以 CodexSandboxOffline 运行。
2. 未经审批创建的文件 owner 是 CodexSandboxOffline。
3. 审批后执行的 shell 命令会以当前 Windows 用户运行。
4. 审批后创建的文件 owner 是当前 Windows 用户。
5. Git 只读命令通常不需要提权。
6. 会写 .git/ 的 Git 命令需要提权。
7. 如果一个项目既由人手动维护 Git，又由 Codex 修改文件，最好让项目工作区 owner 保持为当前用户，并让 Codex 通过审批机制执行 Git 写操作。

我的建议

日常使用可以分工：

Codex 未审批操作：读文件、查状态、跑安全的本地命令、编辑普通工作区文件
Codex 审批后操作：git add、git commit、git lfs install、网络访问、工作区外写入
人类手动操作：最终确认 Git diff、提交、推送

如果希望 Git 使用体验最稳定，项目目录 owner 建议保持为当前用户。Codex 可以继续通过 sandbox 写普通工作区文件；涉及 .git/ 的操作由审批流程明确放行。

这种模型比简单关闭 sandbox 更安全，也比让所有命令都无条件提权更可控。