GitHub Copilot 本地沙箱功能正式可用

这次发布到底是什么

2026 年 10 月 7 日，GitHub 宣布 GitHub Copilot 的本地沙箱功能正式可用。它不是一个新模型，而是给 Copilot 在你自己电脑上执行工具和命令时加的一道安全边界。官方原文说，这个功能已经进入 GitHub Copilot CLI、GitHub Copilot 应用，以及使用 Agent Host 的 VS Code 会话。

它随 GitHub Copilot 提供，官方明确说不需要额外付费。你可以把它理解成：Copilot 还是那个帮你写代码的助手，但现在它动手干活时，被关进了一个有门禁的小房间，能拿什么、能碰什么，由你或你所在组织提前定好规则。

为什么需要本地沙箱

当 Copilot 进入更自主的代理工作流时，它可能自己决定运行命令、读取文件、访问网络或调用本地工具。如果没有边界，这些动作就可能碰到不该碰的东西，比如你的私人文件、登录凭据或公司内网。

本地沙箱要解决的就是这个问题：让开发者敢把更多任务交给 Copilot 自动完成，同时清楚知道它最多只能做到哪一步。官方把它描述为在开发者自己的机器上，为代理工作流提供安全的执行边界。

它具体能限制什么

根据官方说明，本地沙箱可以限制代理运行的命令能读取或修改哪些文件和目录；可以控制对互联网、本地网络、Git 凭据和 GitHub CLI 凭据的访问；还可以把沙箱应用到本地工具和服务，包括在支持的情况下用于本地 MCP 和语言服务器。

这些限制不是写死在程序里的，而是基于开发者或其组织定义的策略。也就是说，同一个 Copilot，在不同团队、不同项目里，可以有不同的活动范围。官方还提到，企业可以通过受管设置要求必须使用沙箱，并强制执行开发者无法自行放宽的策略。

背后的技术怎么理解

官方说本地沙箱由 Microsoft eXecution Container（MXC）驱动。它的作用是把一套通用的沙箱策略，翻译成 Windows、macOS 和 Linux 上各自原生的操作系统控制。这样开发者不用为每个系统单独写一套规则，策略可以跨平台表达。

这里有一个重要区分：模型执行和工具隔离是两件不同的事。沙箱策略只作用于工具执行，不管 Copilot 用的是哪个模型。换句话说，换模型不会让沙箱失效，沙箱也不会因为模型不同而改变规则。

适合哪些人和哪些场景

如果你只是偶尔让 Copilot 补全几行代码，这个功能可能感知不强。但如果你已经在用 Copilot CLI、Copilot 应用或 VS Code 里的代理会话，让它自动跑命令、改文件、连本地服务，那么本地沙箱就是给你准备的安全带。

对企业和团队来说，价值更明显：管理员可以用企业受管设置统一要求沙箱，并锁死策略，避免个别成员为了省事把限制关掉。这样团队就能在可控边界内，更放心地采用更自主的代理工作流。

限制和还没说清楚的地方

官方原文没有说明 MXC 是否开源，也没有给出各操作系统的最低版本要求、策略配置的具体示例，以及企业策略在管理界面中的具体路径。各客户端需要升级到什么版本才能使用，原文同样没有交代。

另外，本地沙箱和云端沙箱的功能差异细节，原文只引导读者去看另一篇说明，没有在 changelog 里展开。因此，如果你要把它写进团队规范，建议先在自己的环境里验证策略生效范围，再逐步扩大使用。

怎么开始核验和使用

官方给出的起点是查看“About cloud and local sandboxes for GitHub Copilot”这篇文档。你可以先确认自己用的客户端是否在支持列表里，再尝试定义一条最小策略，比如只允许读取项目目录、禁止访问网络，然后观察 Copilot 执行命令时的行为是否符合预期。

核验时重点看三件事：被限制的文件是否真的读不到，凭据是否真的拿不到，企业策略是否真的无法被普通成员削弱。确认这些之后，再决定是否把更自主的代理任务交给 Copilot。这样既享受自动化，也守住安全边界。