GitHub Copilot本地沙箱正式可用

GitHub 在 2026 年 10 月 7 日的 Changelog 中宣布，GitHub Copilot 本地沙箱（Local sandboxing）正式可用。它覆盖 GitHub Copilot CLI、GitHub Copilot app，以及使用 Agent Host 的 VS Code 会话；重点不是换一个模型，而是给 Agent 代表用户执行的命令和工具加上一层由开发者或组织定义的本机权限边界。

官方公告：https://github.blog/changelog/2026-10-07-local-sandboxing-for-github-copilot-now-generally-available/

官方文档：https://docs.github.com/en/copilot/concepts/security-governance-and-network-settings/about-cloud-and-local-sandboxes

简单说，本地沙箱让 Copilot 仍在自己的电脑上工作，但命令、工具和受支持的本地服务不再默认拥有当前用户的全部文件、网络和凭据权限。它已经正式可用且无需额外付费，不过启用状态、策略和宿主机支持仍决定最终行为。

这次正式可用，具体覆盖哪些地方

GitHub 公告明确列出三个入口：Copilot CLI、GitHub Copilot app，以及使用 Agent Host 的 VS Code sessions。公告还说明，本地沙箱由 Microsoft eXecution Container（MXC）提供跨 Windows、macOS 和 Linux 的策略翻译，把一套共同的沙箱策略映射到各系统的原生控制能力。

这意味着“正式可用”的核心是执行边界进入产品能力，而不是 Copilot 换了一个新模型。官方还特别区分了模型执行和工具隔离：沙箱策略约束的是工具执行，不取决于当前使用哪一个模型。

它实际限制的是哪些权限

本地沙箱解决的是 Agent 命令“能碰到什么”，而不是替开发者判断“应该做什么”。根据公告和官方文档，目前可以从四类权限理解它的价值：

• 文件系统：限制 Agent 可以读取或修改的文件和目录，避免一次任务越过工作区触碰无关资料。
• 网络：控制互联网和本地网络访问，并可按宿主能力配置允许或拒绝的主机。
• 凭据：控制 Git、GitHub CLI 等凭据是否可用；官方文档还说明，经过代理的凭据可以只对获准的 HTTPS 目的地提供。
• 本地工具与服务：在支持的情况下，把本地 MCP 和语言服务器等服务也纳入沙箱边界。

企业团队还可以用托管设置要求必须启用沙箱，并限制开发者弱化策略。对个人开发者来说，最重要的判断是：策略应该覆盖哪些目录、是否需要网络、哪些凭据必须完全不可见，而不是直接把所有权限一刀切放开。

不要把本地沙箱误读成完整虚拟机

这是我认为最容易被标题带偏的地方。GitHub 文档明确说，本地沙箱目前位于较轻量的一侧：它限制进程能够读取、写入和访问的资源，但不会把命令放进一台独立的虚拟机或完整容器里。MXC 会根据系统选择相应的隔离后端，策略强度和可用控制仍然受操作系统支持影响。

因此，本地沙箱适合降低 Agent 误改文件、误用网络或意外接触凭据的风险，却不能被宣传成“任何恶意代码都能安全运行”的通用执行环境。对于需要强隔离、可复现构建或不信任代码执行的场景，仍要单独评估容器、虚拟机和组织级网络策略。

同样要注意，GitHub 文档把本地沙箱和云沙箱分开：本地沙箱在自己的机器上运行且不额外收费；云沙箱是在 GitHub 托管的隔离环境中运行，计费与组织策略另有说明。两者不是同一条开关。

开始评估时，先做一个最小权限试用

官方文档给出了 Copilot CLI 在当前会话启用本地沙箱的命令：

# 在当前 Copilot CLI 会话启用本地沙箱
/sandbox enable

# 如果策略允许，结束评估时关闭当前会话的本地沙箱
/sandbox disable

第一次评估可以只给项目工作区读写权限，先拒绝无关目录和不必要的网络访问，再观察构建、测试、MCP 或语言服务器是否确实需要额外权限。官方文档说明，CLI 与 Copilot app 的本地沙箱设置是分别配置的，在一个入口开启不会自动改变另一个入口。

如果企业策略要求必须启用，普通设置和启动参数不能绕过它；如果宿主机不支持所需能力，系统可能拒绝执行，而不是悄悄退回到无沙箱模式。这个行为比“先跑起来再说”更适合纳入团队的工程评估。

对开发团队意味着什么

这项变化把 Agent 的安全讨论从“要不要相信模型”推进到“允许它执行哪些动作”。个人项目可以从工作区范围、网络开关和凭据暴露三项开始；团队项目还应把企业托管策略、宿主系统支持情况和沙箱失效时的处理方式写进开发规范。

我的判断是：如果团队已经让 Copilot 自动运行测试、修改文件或调用本地工具，本地沙箱值得优先试用；如果需求是运行不可信代码或提供强合规隔离，它只能作为一层操作系统级防护，不能替代专用隔离基础设施。公告确认的是能力正式可用，具体策略仍要由使用者和组织自己负责。

相关问题

本地沙箱是否需要单独购买？不需要。GitHub Changelog 明确写明它包含在 GitHub Copilot 中，不额外收费。

开启后 Copilot 还能访问网络吗？可以由策略控制，但默认行为和可配置粒度取决于入口、操作系统及组织设置，不能把“启用沙箱”理解成必然断网。

本地沙箱和云沙箱是同一个功能吗？不是。本地沙箱在自己的机器上限制命令权限，云沙箱则运行在 GitHub 托管的隔离环境中，计费与组织启用方式也不同。