AI 编程助手的沙箱终于上线,但默认是关的

10 月 7 日，GitHub 宣布 Copilot 的本地沙箱正式可用：Copilot CLI、Copilot 桌面应用、VS Code 里的 Agent Host 会话，都能限制 AI 执行命令时能读什么、写什么、能访问哪些网络。免费，不用加钱。

听起来是件大好事。但有个细节被很多人直接划过去了：这个沙箱默认是关闭的。在你或企业管理员主动打开之前，AI 助手执行的每一条 shell 命令，用的都是你账户的完整权限——能删你的文件，能读你的密钥，能访问你的内网。

功能上线和功能生效，中间隔着一次没人做的点击。

这次的能力建立在微软的 MXC 执行容器框架上，思路是「一份策略，三端落地」：你定义一份沙箱策略，它自动翻译成各操作系统的原生机制——macOS 上用 Seatbelt，要求 macOS 15 以上；Linux 上用 bubblewrap 加 iptables；Windows 11 支持但不同版本能力有差异。

策略能管的事包括：进程可以读写哪些路径、能不能访问互联网和局域网、能不能看到 Git 和 GitHub CLI 的凭据、本地 MCP 服务器和语言服务器要不要关进沙箱里跑。

对一直担心 Prompt 注入风险的开发者来说，这套东西来得正是时候。AI 编程助手执行的是模型生成的命令，模型会被网页、issue 里的恶意文本带偏，一旦它「决定」执行 curl 一个陌生脚本，沙箱就是最后一道闸。

第一个误区：开了沙箱就万事大吉。GitHub 自己的文档写得很清楚，这不是虚拟机，也不是容器。CLI 内置的文件读写工具是进程内运行的，操作系统级的隔离根本约束不到它们；远端服务器完全不在沙箱范围内；Windows 上的网络限制靠应用自觉遵守代理设置，比 macOS 和 Linux 上弱一档。沙箱是降低风险，不是消灭风险。

第二个误区：功能上线了就等于受保护了。默认关闭意味着，个人用户里真正去敲 /sandbox enable 的比例不会高。这个设计的实际价值更偏向企业管理员——组织可以通过服务端策略、MDM 或配置文件强制开启，而且开发者无法削弱。策略要求开沙箱但系统不支持时，操作会直接失败，而不是降级裸奔，这个取舍做得对。如果你是个人用户，现在就该去把这个开关打开。

第三个误区：同一个版本里还有个容易误读的更新。Copilot CLI 的模型选择器现在能列出本机 Ollama 跑的模型，有人把这理解成「用本地模型 = 数据不出门」。不是的。选本地模型只是换个推理引擎，会话里配置的云端提供商照样能收到你的提示词和代码上下文；真正的离线模式是另一个独立开关，而且开了离线，GitHub 也明确警告并非绝对断网。本地模型是性能和成本选项，不是隐私开关。

单看功能，Copilot 不是第一个做沙箱的编程助手。但把「组织强制、个人不能关、不支持就报错不做」这套组合做到位的，目前还不多。

这背后是 AI 时代权限管理的一个核心矛盾：安全的收益由组织获得，开启的成本却落在每个个人头上。靠自觉，结果一定是大多数机器裸奔；靠强制，才可能把基线抬起来。GitHub 这次显然想明白了这一点。

另外提醒一句，JetBrains、Xcode 等其他 IDE 插件是否跟进沙箱，官方文档没提，用这些入口跑 Agent 的团队暂时还是全权限状态。

AI 助手的权限边界，正在从「信任模型」转向「约束进程」。方向对了，但闸门装好了不等于闸门放下了。你机器上的 Agent，今天是什么权限？

如果你也在用 AI 编程助手干活，把这篇转给团队里管开发环境的人，强制沙箱这件事，越早推越好。看完有想法，评论区聊聊你敢不敢把 Agent 的命令执行放出来。

参考文章

#GitHubCopilot #沙箱 #AIAgent #开发者安全 #权限管理