夜雨聆风资享宝库
科技前沿 · 深度洞察
别把 AI 编程助手直接放进你的电脑：Codex 的 Windows 沙箱，给了一个更现实的安全答案
AI 编程助手越能干，越不能裸奔。真正危险的不是它写错一段代码，而是它在你电脑上拿着完整权限执行错一条命令、读到不该读的密钥、改坏不该改的目录，甚至把本地网络当成默认通道。OpenAI 最近把 Codex 的 Windows 沙箱实现开源，这件事值得拆，因为它不是又一个“安全概念”，而是一套能落到工程细节里的权限隔离方案。
很多人使用 AI 编程助手时，默认假设是：只要模型足够聪明，只要提示词写得清楚，只要我看一眼 diff，就不会出大事。
这个假设在聊天窗口里还勉强成立。一旦助手开始能调用 shell、能安装依赖、能读写文件、能跑测试、能改配置，问题就变了。
你面对的已经不是“一个会给建议的模型”，而是“一个可以在你机器上执行动作的进程”。
进程就必须讲权限边界。
更麻烦的是，AI 编程助手天然会遇到三类高风险动作：它需要读项目文件来理解上下文；它需要写工作区来完成改动；它经常需要运行包管理器、测试脚本、代码生成器、构建命令。这三件事每一件单独看都正常，合在一起就意味着：助手有机会碰到 SSH、云厂商凭证、npm token、Docker 配置、浏览器缓存、本地服务端口、公司内网地址。
所以 Codex 这次 Windows 沙箱真正值得看的点，不是“OpenAI 又做了一个沙箱”，而是它把 AI Agent 在桌面环境里最难处理的一组矛盾摆到了台面上：既要让助手真的能干活，又不能让它拥有用户完整权限；既要兼容 Windows 上复杂的开发工具链，又不能把安全边界做成纸糊；既要支持离线限制，又要保留必要的代理和网络控制。
这篇文章不聊虚的。我们直接从 Codex 代码和公开信息里拆：它到底用了哪些 Windows 机制、为什么普通的“确认弹窗”不够、团队如果要把 AI 编程助手放进真实研发流程，应该照着哪些工程原则落地。
一、这件事为什么现在突然重要
过去一年，AI 编程助手的变化很明显：从“帮你补全代码”，变成“帮你完成任务”。
补全代码时，风险主要集中在结果质量：代码有没有 bug、有没有安全漏洞、风格是否一致。
任务型 Agent 不一样。它会自己决定下一步：读哪些文件、跑什么命令、改哪个配置、装哪个包、是否继续重试。能力越强，动作链越长，安全问题越不可能靠人工盯住每一步。
现在很多团队的问题不是“没有安全意识”，而是安全模型太粗糙：
- 要么完全信任，把终端权限全给助手；
- 要么完全不信任，每条命令都弹窗审批，效率被打碎；
- 要么只靠提示词约束，例如“不要读取敏感文件”“不要访问外网”；
- 要么只在云端沙箱里跑，绕开了本地开发环境，但也牺牲了真实项目里的很多上下文。
这几种方案都有明显缺口。
完全信任最危险，因为模型不是传统程序。它可能因为上下文误解、工具输出误读、依赖脚本副作用、prompt injection，做出用户没有预期的动作。
每条命令都审批也不现实。开发过程里真正高频的是低风险动作：读取源码、跑单测、查看 git diff、生成中间文件。如果每一步都让人点确认，用户很快会形成肌肉记忆，最终把审批当成验证码一样随手点掉。
提示词约束更不够。提示词是意图层约束，不是系统层约束。一个进程如果在操作系统层面能读到 ~/.ssh、~/.aws、.npmrc、.kube，那你就不能把“不读”建立在模型自觉上。
云端沙箱适合 CI、批处理、一次性任务，但本地开发有自己的现实：Windows 用户大量存在；公司项目依赖本地工具链；有些测试依赖本地 SDK、数据库、浏览器、GPU、内网模拟服务。只说“都放进容器”很轻松，真落地时并不总是成立。
所以 Windows 本地沙箱这个方向很关键。它回答的是一个越来越普遍的问题：当 AI Agent 必须在用户电脑上干活时，权限边界到底应该长什么样？
二、Codex 没有把沙箱做成一个开关，而是做成两套后端
从 Codex 仓库能看到，它的 Windows 沙箱不是一句“启用安全模式”这么简单。核心上分成两类模式：非提升权限的受限令牌模式，以及需要管理员初始化的 elevated 模式。
配置侧能看到类似 windows.sandbox、windows_sandbox_mode、WindowsSandboxLevel 这样的分层：禁用、受限令牌、提升沙箱。代码里还有兼容旧 feature flag 的逻辑，说明这套能力不是一次性补丁，而是在逐步替换旧安全路径。
为什么要做两套？因为 Windows 上的权限控制有一个很现实的限制：你想限制写入，和你想限制读取，难度不是一个级别。
受限令牌模式依赖 Windows 的 CreateRestrictedToken、WRITE_RESTRICTED 等机制。它适合控制“这个进程能不能写某些地方”。这对 Agent 已经很有价值，因为最直接的破坏往往来自写操作：删文件、改配置、覆盖构建产物、污染仓库。
但 Codex 代码里也明确暴露了一个关键限制：受限令牌后端无法可靠地把“deny-read”做成权威边界。原因是 WRITE_RESTRICTED 类型的限制主要参与写权限判断，不能保证所有读限制都按预期生效。因此当策略要求更细的读隔离时，Codex 会拒绝在非提升后端里假装安全，而是要求 elevated 后端。
这个设计非常重要。
很多安全产品最容易犯的错，是把“做不到”包装成“已保护”。Codex 的处理更像工程系统：能力边界在哪里，就在代码里承认边界，不把不完整能力伪装成完整能力。
提升沙箱模式的思路更重：它会准备专门的沙箱用户，例如代码中能看到 CodexSandboxOffline 和 CodexSandboxOnline 两类身份；它会维护 .sandbox、.sandbox-bin、.sandbox-secrets 等目录；它会记录 setup marker 和用户凭证；它会根据策略刷新读写根目录、deny-read、deny-write、网络代理设置。
换句话说，Codex 没有试图用一个“低权限进程”解决全部问题，而是把权限隔离拆成多层：进程令牌、专用用户、文件 ACL、能力 SID、网络过滤、私有桌面、辅助 runner。
这才是本地 Agent 沙箱该有的复杂度。
三、文件系统的关键不是“只允许项目目录”，而是读写权限要分开设计
很多团队设计 Agent 权限时，会说一句看似合理的话：只允许它访问项目目录。
问题在于，项目目录本身并不干净。
真实项目里经常有 .env、测试私钥、临时 dump、数据库连接串、本地缓存、生成证书、公司内部配置。更现实的是，项目构建工具并不只读项目目录。它可能读用户目录下的包管理器缓存、全局配置、SDK、系统目录、Git 配置、证书存储。
所以一个可用沙箱不能简单粗暴地说“除了项目目录都禁掉”。那会导致大量工具链跑不起来。
Codex 代码里有一组默认读根目录很有代表性：C:\Windows、C:\Program Files、C:\Program Files (x86)、C:\ProgramData。这些目录不是为了给 Agent 更多自由，而是为了让基础命令和开发工具能正常启动。
同时，它又显式排除一批用户目录下的敏感位置：.ssh、.gnupg、.aws、.azure、.kube、.docker、.npm、.terraform.d 等。这个列表非常工程化，因为它直指真实开发机上的高价值凭证。
更进一步，Codex 不是只做“允许读哪些根目录”，还做了 deny-read 的策略处理。对不可读路径，它会解析精确路径和 glob；对已经存在的路径，会考虑 canonical 路径；对 reparse point 这类绕路访问，也要尽量覆盖真实目标。这里的关键不是语法漂亮，而是防止“路径字符串被禁了，但同一个对象通过另一个路径又能读到”。
写权限也不是一刀切。Codex 用 workspace capability SID 这类机制，把写能力绑定到具体工作区或写根目录。这样 Agent 可以在项目里改代码、生成文件、跑测试，却不应该顺手改用户目录、系统目录、全局工具配置。
对团队落地来说，这里有一个很直接的启发：
不要把 Agent 权限写成“项目目录允许，其他禁止”这么粗。
更合理的模型应该是：
- 系统和工具链目录：默认只读，保障命令能启动；
- 工作区源码：按任务授予写权限；
- 凭证类目录：默认不可读，不靠提示词；
- 包管理器缓存：尽量只读或临时隔离；
- 生成物目录：允许写，但最好可清理、可回滚；
- 额外目录：按任务显式加入，不要长期全局开放。
这套分层看起来麻烦，但它比“每次都问用户能不能执行”更可控。因为审批解决的是单次动作，权限模型解决的是动作空间。
四、网络权限不能只靠“允许或禁止联网”
AI 编程助手的网络权限更棘手。
完全禁止联网会影响很多正常任务：安装依赖、查包版本、下载测试资源、访问企业内部 registry、调用本地代理。
完全允许联网则很危险：一旦出现 prompt injection、恶意依赖脚本、被污染的构建命令，敏感文件可能被外传；Agent 也可能访问不该访问的内网服务。
Codex 在 Windows 沙箱里做了一个值得注意的区分：离线用户和在线用户。代码中出现了 CodexSandboxOffline 与 CodexSandboxOnline，同时还有 WFP，也就是 Windows Filtering Platform 相关模块。WFP 是 Windows 网络过滤的底层机制之一，可以按用户、协议、端口等维度配置过滤规则。
这说明它不是简单地在应用层说“这次别联网”，而是在系统网络层给不同沙箱身份配置不同出站能力。
这类设计对 Agent 非常重要。
因为 Agent 的联网行为不一定来自它主动调用的“浏览网页工具”。很多网络访问发生在间接层：npm install 的 postinstall、pip 下载依赖、测试脚本访问外部 API、构建工具拉二进制、Git hooks、语言服务器插件、包管理器脚本。
如果只在工具层限制“浏览器不能访问外网”，这些间接网络行为仍然可能发生。
更好的做法是把网络权限下沉到进程身份或网络命名空间层。Windows 没有 Linux namespace 那样统一好用的模型，所以 Codex 用专用用户配合 WFP，是一个很现实的路线。
企业落地时，可以直接借鉴这套思路：
- 默认 Agent 运行在离线身份下；
- 只有安装依赖、访问指定 registry、调用指定内部服务时，才切到受控在线身份；
- 在线身份不等于全网通，而是白名单端口、白名单代理、白名单域名或企业网关；
- 网络日志必须和任务 ID、用户、仓库、命令关联，方便事后审计；
- 本地回环地址也要谨慎，因为很多敏感服务只监听 localhost。
尤其要注意尤其要注意的一点。很多人以为 localhost 很安全，但开发机上常见本地服务包括数据库、调试端口、浏览器远程调试、云 CLI 本地缓存服务、公司内部代理。Agent 如果能随便访问 localhost，仍然可能绕过你以为的网络边界。
五、私有桌面这个细节，说明桌面 Agent 的风险比服务器 Agent 更复杂
Codex Windows 沙箱里还有一个容易被忽略但很有意思的点：private desktop。
代码里能看到 sandbox_private_desktop、LaunchDesktop::prepare、CreateProcessAsUserW 启动时设置 lpDesktop 等逻辑。注释里也提到，一些进程比如 PowerShell，在受限令牌下如果没有明确设置桌面，可能出现初始化失败。
这说明 Windows 桌面环境里的 Agent 沙箱，不只是文件和网络问题。它还涉及交互桌面、窗口站、剪贴板、GUI 进程、控制台、ConPTY 等一堆历史包袱。
服务器上的沙箱通常更干净：进程、文件系统、网络、cgroup、namespace，模型比较直。
桌面端不一样。一个进程可能弹窗，可能访问剪贴板，可能通过 GUI 自动化看到窗口内容，可能继承用户会话里的环境变量和句柄，可能因为桌面权限不足导致工具链莫名失败。
这也是为什么“在 Windows 上做一个安全可用的 Agent”比很多人想的难。
如果你做的是企业内部编程助手，千万不要低估这些桌面细节。尤其是以下场景：
- Agent 运行测试时启动浏览器；
- 脚本弹出登录窗口或权限窗口；
- 工具链读取剪贴板或系统凭证管理器；
- 命令在 PowerShell、cmd、Git Bash、WSL 之间切换；
- 用户机器上装了各种全局插件和 shell profile。
很多“偶发安全问题”其实不是模型问题，而是进程启动环境过于接近真实用户会话。
Codex 把 private desktop 做成可配置项，体现的是一种更成熟的思路：当 Agent 需要运行在桌面环境里时，不能默认它和用户共享所有交互资源。哪怕一开始只是为了兼容 PowerShell，最终也会变成桌面隔离的一部分。
六、光有沙箱还不够，必须有“失败时拒绝裸跑”的工程纪律
安全系统最怕的不是出错，而是出错后自动降级成无保护状态。
这点在 AI Agent 里尤其常见。比如：沙箱初始化失败了，为了“不影响体验”，系统直接用普通权限执行；网络代理配置失败了，命令仍然继续跑；路径解析异常了，就当作没有 deny 规则；读写策略太复杂了，就回退到全盘访问。
这类降级一旦出现，用户看到的可能只是“任务完成了”，但安全边界已经不存在。
Codex 代码里有不少“拒绝假装安全”的信号。例如前面提到的：非提升受限令牌后端不能强制执行细粒度读隔离时，会拒绝运行而不是无沙箱继续。setup 也有 marker、error report、setup version、firewall verification 等机制，用来判断沙箱准备是否完整。
这背后的原则很简单：
沙箱失败，任务应该失败；不能因为用户想要结果，就让 Agent 静默拿到完整权限。
对企业来说，这条原则比任何具体实现都重要。
你可以不用 Codex 这套代码，也可以选择容器、虚拟机、远程开发环境、EDR 集成、内部代理。但无论哪种路线，都必须把失败策略写清楚：
- 权限策略解析失败，不能执行；
- 沙箱启动失败，不能执行；
- 网络限制配置失败，不能执行联网命令；
- 敏感路径 deny 规则应用失败，不能继续；
- 审计日志写入失败，至少不能执行高风险动作；
- 检测到 world-writable 目录破坏隔离时，要明确提示风险。
Codex 里对 world-writable 目录也有扫描和提醒逻辑。这个细节很实际：如果某个目录对 Everyone 可写，再精细的写权限隔离也可能被绕出问题。很多团队做权限设计只看自己的策略文件，却忘了底层文件系统 ACL 早就被本机环境污染了。
所以沙箱不只是“运行时限制”，还包括运行前环境体检。
七、不要把“用户确认”当成安全边界
很多 AI 工具的默认安全体验是弹窗：这条命令是否允许？这个文件是否允许修改？是否允许联网？
弹窗有价值，但它不是边界，只是交互。
边界必须由系统强制执行。
原因很简单：用户不可能判断每条命令的完整副作用。比如一条看似普通的 npm test，可能触发 pretest 脚本；一条 pip install -e .，可能执行构建后端；一条 cargo build，可能运行 build script；一条 PowerShell 命令，可能展开 profile、模块、别名、环境变量。
用户看到的是命令字符串，系统执行的是一整条副作用链。
如果你把安全建立在“用户看懂并确认”上，等于要求每个开发者同时懂模型行为、shell 语义、包管理器脚本、操作系统权限、网络路径、供应链攻击。这不现实。
更合理的做法是：
用户确认用于表达意图，沙箱用于限制结果。
比如用户允许 Agent 跑测试，不代表 Agent 可以读取 .aws/credentials；用户允许安装依赖，不代表 postinstall 可以访问全网；用户允许修改当前仓库，不代表可以改全局 Git 配置；用户允许读取项目，不代表可以读取相邻目录的客户数据。
确认弹窗应该变成策略切换入口，而不是唯一保护措施。
一个更好的交互应该是：
- 低风险读操作自动通过，但限定在允许读根内；
- 工作区写操作自动通过，但只能写授权根；
- 涉及联网时，展示联网目的和将使用的网络身份；
- 涉及敏感路径时，不是询问“是否读取”，而是默认拒绝，并要求用户显式临时授权；
- 涉及全局配置、凭证目录、系统目录时，必须升级审批并记录审计。
这样用户才是在管理策略，而不是被迫审查 shell 细节。
八、团队可以直接照抄的 Agent 沙箱清单
如果你现在负责把 AI 编程助手接入团队研发环境，不需要等所有平台都成熟。可以先按下面这套清单做最小可用版本。
▎1. 先把权限分成四类，不要只分“允许/禁止”
第一类是只读基础环境：系统目录、语言运行时、编译器、SDK、只读依赖缓存。
第二类是可写工作区：当前仓库、任务临时目录、测试输出目录、构建缓存目录。
第三类是敏感不可读：SSH、GPG、云厂商凭证、Kubernetes、Docker、npm token、Terraform、浏览器数据、密码管理器导出文件。
第四类是临时授权资源：某个外部目录、某个内部服务、某个包 registry、某个一次性密钥。
只要这四类没分清，后面的审批、审计、回滚都会混乱。
▎2. 默认离线，按任务打开网络
Agent 不应该默认全网通。默认离线会逼迫系统把联网意图显式化。
需要联网时，至少记录：命令、目标、时间、用户、仓库、任务 ID。更理想的是统一走企业代理，由代理做域名级控制和日志。
▎3. 不要让 Agent 继承完整用户环境
很多泄漏来自环境变量和 shell profile。Agent 进程应该使用最小环境变量集合，PATH 也应经过整理。Codex 里有非交互 pager、PATH 继承、null device 规范化等处理，说明真实工具链里这些小细节会影响稳定性。
企业实现时也要注意：不要把用户终端里的所有变量原样传给 Agent。
▎4. 高风险目录默认不可读，而不是读了以后不展示
有些产品会说“模型不会把密钥展示给用户”。这不是安全。密钥一旦被进程读到，就可能进入上下文、日志、缓存、工具输出、错误栈。
正确做法是操作系统层面不可读。
▎5. 审计要记录动作空间，不只记录最终 diff
只看最终代码 diff 不够。你还要知道 Agent 跑了哪些命令、读了哪些敏感边界附近的路径、是否触发联网、是否失败降级、是否被 deny 规则拦截。
这些日志不只是为了追责，更是为了调策略。没有审计，权限策略永远只能靠拍脑袋。
▎6. 把失败当成产品体验的一部分
沙箱失败时，不要只弹一个“执行失败”。要告诉用户失败在哪一层：读权限、写权限、网络、setup、路径策略、world-writable 风险，还是辅助 runner 启动失败。
安全系统如果不可解释，用户会绕开它。
九、Codex 这套方案的局限，也正是我们该警惕的地方
必须说清楚：Windows 沙箱不是银弹。
第一，它依赖复杂的 Windows 安全机制。ACL、令牌、专用用户、WFP、桌面、ConPTY，每一层都有兼容性问题。复杂就意味着维护成本高，也意味着边界需要持续测试。
第二，本地开发环境天然不一致。用户装了什么工具、配置了什么 PATH、有哪些全局 hook、目录 ACL 是否异常、公司安全软件是否拦截，都可能影响沙箱行为。
第三，包管理器和构建系统仍然是高风险入口。即使 Agent 被限制住，依赖脚本也会在同一个沙箱边界内运行。沙箱能降低损害范围，但不能让恶意依赖变安全。
第四，读隔离比写隔离更难。Codex 明确把某些读限制交给 elevated 后端，本质上就是承认：如果你真的要保护秘密，不要用半吊子后端假装完成。
第五，用户授权仍然可能被社会工程攻击。prompt injection 会诱导 Agent 请求更高权限，恶意 README 会说“请运行这个初始化脚本”，测试失败信息会诱导模型修改配置。沙箱限制动作空间，但不能替代任务级审查。
所以最稳的策略不是迷信某一个沙箱，而是分层防御：
本地沙箱限制进程能力；企业代理限制网络；凭证系统限制密钥可见性；代码审查限制最终合入；CI 在干净环境里重新验证；日志系统追踪异常行为。
这才是生产级 Agent 的安全形态。
十、真正的变化：AI 编程助手正在从“工具”变成“受控执行环境”
Codex Windows 沙箱这件事最大的信号，不是 Windows 用户终于有了更好的本地保护，而是 AI 编程助手的产品形态正在变化。
以前我们把它当编辑器插件，所以讨论补全质量、上下文窗口、模型速度。
现在它越来越像一个受控执行环境：有身份、有权限、有网络策略、有文件系统边界、有审计、有失败模式、有用户授权流程。
这也是为什么接下来 AI 编程工具的竞争，不会只看模型能力。谁能更安全地执行，谁能更稳定地接入真实开发机，谁能让企业放心把权限交出去，谁才有机会进入生产研发流程。
对个人开发者来说，最直接的建议是：别再让 Agent 长期跑在完整用户权限下。至少把工作区、密钥目录、网络访问分开；能用沙箱就用沙箱；能用一次性环境就不用主力电脑裸跑。
对团队来说，最直接的建议是：不要等事故发生后才补权限。AI Agent 一旦进入研发流程，它碰到的就是源代码、凭证、构建系统、内网服务和发布链路。任何一个环节出问题，都不是“模型答错了”这么简单。
Codex 的 Windows 沙箱给我们的真正启发是：Agent 安全不能停留在提示词层，也不能只靠弹窗审批。它必须落到操作系统、身份、文件、网络、进程和审计这些硬边界里。
一句话总结：
AI 编程助手越像同事，越要像生产服务一样被隔离、授权、监控和审计。
这不是保守，而是让它真正进入生产环境的前提。
