Codex的windows沙箱机制下找不到WinGet安装的工具

Codex在Windows的Elevated Sandbox下，并不是直接用当前登录用户执行命令。

它会创建独立的本地普通用户：

CodexSandboxOffline

CodexSandboxOnline

然后让真正的命令以这些沙箱用户身份运行，并配合Restricted Token、ACL和网络规则做隔离。

所以：你安装软件的用户≠Codex实际执行命令的用户

这会带来两个问题。

1.User Scope工具对Codex不可靠

WinGet默认把工具安装到：

C:\Users\你的用户名\AppData\Local\...

这是当前用户自己的目录。

即使PATH里能找到uv.exe、ffmpeg.exe，Codex沙箱用户也可能因为ACL没有读取/执行权限而无法启动。

所以我建议把WinGet改成强制Machine Scope：

{

    "$schema": "https://aka.ms/winget-settings.schema.json",

    "installBehavior": {

        "requirements": {

            "scope": "machine"

        }

    }

}

这样工具会尽量安装到系统级位置，例如：

C:\Program Files\...

更适合Codex这种跨用户沙箱调用。

2.WinGet的Portable包还有一个ACL坑

像ffmpeg、uv这类Portable/ZIP包，全局安装后通常位于：

C:\Program Files\WinGet\Packages

命令入口则在：

C:\Program Files\WinGet\Links

但WinGet存在一个已知问题：

Machine Scope安装的部分Portable包，没有正确给普通Users组继承读取和执行权限。

于是会出现：

安装工具的用户：能运行

CodexSandboxOffline：属于另一个普通用户，没有 RX 权限，Access Denied/ResourceUnavailable

我的ffmpeg和uv都遇到了这个问题。

最终解决办法

用管理员 PowerShell 执行：

icacls "C:\Program Files\WinGet\Packages" /grant '*S-1-5-32-545:(OI)(CI)RX' /T /C

其中：

S-1-5-32-545 = BUILTIN\Users

RX = Read + Execute

也就是说给所有普通本地用户增加读取和执行权限，但不给写入权限。

而Codex创建的Sandbox用户本身就是BUILTIN\Users成员，所以处理后就可以正常运行这些工具。

最终逻辑就是：

Codex使用独立普通用户执行命令

        ↓

User Scope工具跨用户访问不可靠

        ↓

改成Machine Scope

        ↓

WinGet Portable又存在ACL继承问题

        ↓

给BUILTIN\Users补RX

        ↓

Codex可以正常调用ffmpeg / uv等工具

所以这个问题本质上不只是PATH，而是：

安装Scope

+

PATH

+

ACL

三者缺一不可。

省流

由于Codex的windows沙箱机制，WinGet安装推荐使用全局安装 + 给C:\Program Files\WinGet\Packages 补users权限。