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权限。