GitHub Copilot 的本地沙箱能力已正式 GA，覆盖 GitHub Copilot CLI、GitHub Copilot 应用，以及使用 Agent Host 的 VS Code 会话。这意味着开发者可以在自己的机器上，为 Agent 驱动的自动化工作流建立一条安全执行边界。
本地沙箱解决什么问题
Agent 模式与普通代码补全的关键差异在于：Agent 会主动发起工具调用和命令执行。一旦命令在本机运行，它天然拥有当前用户的文件系统、网络和凭据访问能力。本地沙箱的目标，就是把这些能力收窄到策略允许的范围内。
根据官方说明，Copilot 发起的工具和命令会在受限条件下运行，限制对象包括文件系统、网络、凭据以及其他系统能力。限制依据来自开发者或其组织定义的策略。
隔离机制：MXC 与策略翻译
本地沙箱由 Microsoft eXecution Container（MXC）提供支持。MXC 的职责是把一份通用沙箱策略翻译为各操作系统原生的控制手段，从而在 Windows、macOS 和 Linux 上提供一致的策略语义。
这里有一个容易被忽略的边界：模型执行与工具隔离是两件独立的事。沙箱策略作用于工具执行，与 Copilot 使用哪个模型无关。也就是说，无论底层模型如何切换，工具执行始终受同一套策略约束。
可控制的权限维度
官方列出本地沙箱支持的能力范围：
- 限制 Agent 运行的命令可以读取或修改的文件与目录。
- 控制对互联网、本地网络、Git 凭据和 GitHub CLI 凭据的访问。
- 对本地工具和服务应用沙箱，包括在支持的情况下对本地 MCP 和语言服务器生效。
- 使用企业托管设置强制要求沙箱，并执行开发者无法削弱的策略。
- 在保持 Copilot 可访问范围边界清晰的前提下，采用更自主的 Agent 工作流。
从工程视角看，这几项覆盖了 Agent 风险的主要面：数据外泄（网络与凭据）、横向移动（本地网络）、持久化破坏（文件系统写入），以及工具链扩散（MCP、语言服务器）。
企业落地的配置思路
官方明确本地沙箱随 GitHub Copilot 提供，不额外收费。企业侧的关键抓手是“企业托管设置”：组织可以要求启用沙箱，并下发开发者无法自行放宽的策略。
结合上述能力，企业落地时可以考虑以下分层：
- 基线强制。通过企业托管设置要求沙箱开启，避免个别开发者关闭隔离。
- 凭据隔离。默认禁止 Agent 命令访问 Git 与 GitHub CLI 凭据，仅在明确需要的仓库或任务中放开。
- 网络收敛。默认限制互联网与本地网络访问，按需为依赖拉取等场景开放白名单。
- 文件系统最小化。只授予当前工作区所需目录的读写权限，避免暴露主目录下的敏感配置。
- 工具面治理。对本地 MCP 和语言服务器同样套用沙箱策略，防止绕过主执行路径。
边界与注意事项
需要区分事实与推断。官方资料确认了沙箱覆盖的范围和策略来源，但并未给出具体的策略文件格式、默认策略内容或各平台底层实现细节。因此在实际配置时，应以官方文档《About cloud and local sandboxes for GitHub Copilot》为准，而不是依赖推测。
另外，沙箱是执行边界，不是完整的安全方案。它约束的是 Agent 发起的工具执行，企业仍需在代码审查、依赖治理和凭据轮换上保持既有实践。
结论
本地沙箱 GA 的意义在于，把 AI 编程 Agent 从“能执行”推进到“可控执行”。对开发者而言，它降低了在本机运行自主 Agent 的心理门槛；对企业而言，企业托管设置提供了可强制、不可削弱的策略下发通道。是否采用更自主的 Agent 工作流，取决于组织能否把文件、网络和凭据三类边界定义清楚。