2026 年 9 月 23 日，GitHub 给 Copilot 应用加了一项公开测试能力：本地沙箱。它让开发者逐项目地决定，智能体可以读写哪些文件夹、能否访问互联网与本地网络、能否使用 Git 与 GitHub CLI 的凭证。最关键的设定有两条——默认关闭，以及如果操作系统无法强制执行所请求的策略，会话会直接失败，而不是带着保护缺失继续跑。
把编码智能体圈在本机的一块地里
这则更新看着小，指向的却是智能体安全里最容易被忽略的一层：开发者的本机。云端沙箱、托管运行时讨论得很多，可真正天天和智能体打交道、把代码仓库与一堆凭证交给它的，恰恰是本地这台机器。Copilot 的做法是把边界做成可配置的围栏——哪些目录可读写、是否放行网络、Git 与 GitHub CLI 的令牌能不能用，全部按项目来定，而不是一刀切。会话中途也能用 /sandbox on 临时开启，给的是可控的灵活，不是无条件的开放。
为什么这件事值得单列出来讲，而不是当成又一个 Copilot 小更新？因为本地机器是智能体攻击面里最不对称的一环。云端沙箱至少还有平台方统一的安全基线和审计，本机却是千人千面：有人开着明文凭证，有人把生产密钥塞在环境变量里，有人仓库里躺着能直接推主干的令牌。当一个编码智能体被允许在本机读写、联网、调用 Git 时，它碰到的不是一处受控环境，而是开发者日常积累的全部信任关系。把边界收回开发者自己手里，等于承认了这件事实：最危险的执行环境，往往不是云，而是那台连着一切的开发机。GitHub 这步的克制之处，是没有替开发者决定边界，而是把决定权连同失败关闭的默认，一起交还给了项目和人，让安全重新落回责任人手里。这也提醒做智能体产品的团队：沙箱的价值不在于它存在，而在于它失败时如何收场。
这条更新的设计里，值得放大的是失败关闭四个字。过去不少安全机制是失败开放的：一旦底层环境撑不住所声明的策略，程序照跑不误，只在日志里留个口子，于是真实运行里出现一段没人看见的裸奔窗口。GitHub 这处的取向相反——策略执行不了，会话就停下。这种取向和此前一些编码智能体工具安装时的失败开放缺陷，恰好形成对照：同样是策略能否落地，失败时是停还是跑，直接决定了这道控制到底算不算数。
默认关闭，是一把双刃剑
也必须看到，默认关闭意味着大多数用户短时间内不会主动打开它。一项安全控制的价值，终究取决于被多少人真正启用；写在文档里、藏在设置里，和跑在生产里，是三件不同的事。对团队来说，更有意义的做法可能是把它编进项目模板与 CI 检查，让沙箱成为新仓库的出厂设置，而不是靠每个开发者手动开启。而在这道控制里，最该被盯紧的一格，是 Git 与 GitHub CLI 的凭证范围——智能体一旦拿到能推送代码的令牌，它的破坏半径就不再限于读几个文件。
把本周几则安全事件串起来看，Cloudflare 的磁盘残留、OpenAI 的沙盒逃逸、OX 的 MCP 供应链缺口，和 GitHub 这处本地沙箱，其实说的是同一件事的不同侧面：智能体的边界正在从模型会不会乱说，下沉到它能不能碰到它不该碰的东西。GitHub 这步没有宣称解决了什么问题，它只是把开发者手里那道最贴身的围栏，做成了可关可开、失败即停的样子。对用 Copilot 写代码的团队，现在值得做的，是把这道围栏默认打开，并先把凭证范围收得最小。