GitHub 于 2026 年 9 月 23 日公布 Copilot App 的本地 sandboxing 公开预览。新功能的目的，是降低代理执行意外指令时的影响范围，按项目限制它可以读写哪些文件、连接哪些网络，以及是否可以使用 Git 和 GitHub CLI 凭证。
设置以项目为单位，包括额外可读写文件夹、额外只读文件夹和拒绝访问文件夹；网络部分可控制外部互联网和本地网络；凭证部分则包括用于已验证 HTTPS Git 操作的 Git credential，以及 GitHub CLI authentication。这比单纯为整个电脑开一个总开关更接近真实开发流程，因为不同 repository 的信任边界可以不同。
GitHub 说，这些设置是 Copilot 启动 sandboxed session 时要求的政策，实际有效政策可以因 enterprise-managed settings 而更严格。还有一个重要的故障安全行为：如果操作系统无法执行所要求的政策，sandboxed shell 会直接失败，而不是退回到没有 sandbox 的模式。这种 fail-closed 设计可避免用户误以为代理仍在受限环境内运行。
功能目前默认关闭。用户要在 App settings 选择项目，再开启 Sandbox new sessions；设置只适用于新的工作阶段，现有 session 不会即时重置。现有工作阶段也可以输入 `/sandbox on` 启用，但修改文件、网络和凭证政策，通常要等新 session 或重新启动才生效。
本地 sandbox 不会适用于 cloud sandbox 或 remote host，而且 Copilot App 与 Copilot CLI 的 sandbox 设置分开管理。这个范围界线很重要：企业不能假设在一个界面设置的限制会自动延伸到另一个代理执行环境，必须分别审查执行位置、网络路径和可用凭证。
从代理治理角度看，sandbox 解决的是执行层面的隔离，不是模型判断本身。它可以缩窄错误指令的文件、网络和身份影响，但不能代替代码审查、版本控制、最小权限、secret rotation 或人工批准。允许某个文件夹写入，也不代表所有写入内容都安全；团队仍需在结果层面做测试和审阅。
这次公开预览也提醒采用者先画清楚工作区边界，再让代理执行。适合的起点是没有生产凭证的测试 repository，先限制外部网络和敏感数据，记录代理要求的权限，再按需要放宽。如果遇到 sandbox 不支持或政策解析失败，应把错误当成需要修正的部署问题，不应以关闭限制作为快速解决方案。
对本地 AI coding agent 而言，安全不只是模型能否拒绝危险指令，也包括系统在指令成功执行时可以碰到什么。GitHub 把文件、网络和凭证拆成可配置的项目政策，并在无法强制时选择失败，让代理工作流更接近可审计的工程系统，而不是一个拥有整台电脑权限的黑盒。
