---
title: "Copilot 沙箱 10 月 7 日正式可用：它限制什么、谁来开、5 步自查"
description: "GitHub 在 2026 年 10 月 7 日宣布 Copilot 本地沙箱正式可用，不额外收费。本文说明它能限制文件、网络和凭据中的哪些权限、在哪些入口可用、企业怎么强制开启，并给出一份开启后的 5 步自查清单。"
url: https://cdnping.org/blog/github-copilot-local-sandboxing-ga
language: zh-CN
published: 2026-10-18
category: "开发工具"
tags: ["GitHub Copilot","沙箱","AI Agent","开发安全","MXC"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# Copilot 沙箱 10 月 7 日正式可用：它限制什么、谁来开、5 步自查

2026 年 10 月 7 日，GitHub 宣布 Copilot 的本地沙箱（local sandboxing）正式可用（GA）。简单说：Copilot 的 Agent 在你机器上运行的工具和命令，可以按策略被限制在一个边界里，访问哪些文件、能不能联网、能不能用 Git 凭据，都由你或你的组织定义。官方说明这项功能包含在 GitHub Copilot 中，没有额外费用。

这篇文章讲 Copilot 沙箱到底限制了什么、哪些入口能用、企业怎么管，以及开启后建议做的自查。以下内容截至 2026 年 10 月，来自 GitHub 官方公告。

## Copilot 沙箱是什么，在哪些地方能用？

根据 [GitHub 的公告](https://github.blog/changelog/2026-10-07-local-sandboxing-for-github-copilot-now-generally-available/)，本地沙箱目前在三个入口可用：

- GitHub Copilot CLI
- GitHub Copilot app
- 使用 Agent Host 的 VS Code 会话

底层是 Microsoft eXecution Container（MXC）。它把一份通用的沙箱策略，映射到 Windows、macOS、Linux 各自的原生系统控制上，所以同一套策略可以跨平台使用。MXC 项目在 [GitHub 上公开](https://github.com/microsoft/mxc)，具体实现细节以项目和官方文档为准。

有一点容易混淆：沙箱隔离的是工具执行，不是模型本身。公告明确说，无论 Copilot 使用哪个模型，沙箱策略都作用于工具执行。

## 为什么 Agent 需要沙箱？

Agent 和补全不同，它会自己决定执行什么命令。常见的担心有三类，这是 Agent 工作方式带来的一般性风险，并非本次公告里的案例：

- 命令误操作，比如在错误目录里批量删除或覆盖文件；
- 读到不该读的东西，比如环境变量、密钥文件、Git 凭据；
- 向不该访问的地址发请求，把代码或数据带出去。

靠“每条命令都点确认”防这些事，时间一长人会疲劳。沙箱换了个思路：先划边界，边界内的操作不用反复确认，越界的直接拦下。

## 它具体能限制什么？

公告列出的能力如下：

| 控制对象 | 说明 |
|---|---|
| 文件与目录 | 限制 Agent 运行的命令可以读取或修改哪些路径 |
| 网络 | 控制互联网和本地网络访问 |
| 凭据 | 控制 Git 凭据和 GitHub CLI 凭据的访问 |
| 本地工具与服务 | 在支持的情况下，也适用于本地 MCP 服务器和语言服务器 |

注意“在支持的情况下”这几个字：不同工具能不能被纳入，以官方文档为准。官方概念文档在这里：[About cloud and local sandboxes for GitHub Copilot](https://docs.github.com/copilot/concepts/security-governance-and-network-settings/about-cloud-and-local-sandboxes)。

## 企业和团队怎么管？

公告提到两点：企业可以通过托管设置（enterprise-managed settings）要求开启沙箱；组织可以下发策略，且开发者不能把它放宽。如果你是管理员，先在官方文档里确认托管设置的具体位置和字段，不要凭印象配置。

## 开启之后怎么自查？（5 步）

具体的开关和配置项名称请以官方文档为准，下面是思路上可以照做的检查：

1. **确认入口已生效。** 分别在 Copilot CLI、Copilot app、VS Code Agent Host 会话里确认沙箱处于开启状态；三个入口各自独立，别只查一个。
2. **收紧文件范围。** 只放行当前项目目录，不要放行整个用户主目录。`~/.ssh`、云厂商凭据目录、浏览器配置目录默认不应出现在可读范围里。
3. **默认限制网络。** 先不放行，等 Agent 真的因为拉依赖被拦下时，再按官方文档支持的粒度逐项放行，而不是一开始全开。
4. **按需放凭据。** Git 和 GitHub CLI 凭据只在确实需要 push 或调用 API 的任务里放行。
5. **做一次越界测试。** 在测试仓库里让 Agent 读一个范围外的文件、访问一个未放行的地址，确认它被拦截，并看日志或提示是否清楚。这一步决定你的策略是真生效还是写在纸上。

## 其他工具有类似做法吗？

有。很多 Agent 类工具都提供某种形式的权限、沙箱或钩子机制，例如 Codex 有自己的 sandbox 设置，Claude Code 有权限规则和 hooks。它们的名称、默认值和能力差别不小，本文没有逐一核对，请以各家官方文档为准，不要把 Copilot 的策略直接套过去。

同一周的 [Copilot 每周更新](https://github.blog/changelog/2026-10-09-github-copilot-weekly-releases-october-5/)还提到，Copilot CLI 的 `/model` 现在可以列出本机运行的 Ollama 里的模型。这与沙箱是两件事，但值得放在一起看：模型换成本地的，工具执行仍然需要边界。

## 沙箱不能解决什么？

沙箱管的是“命令能碰什么”，不是“代码写得对不对”。Agent 在允许的目录里写出有漏洞的代码、改坏测试，沙箱不会拦。代码审查和测试仍然需要。另外，放行的权限越多，沙箱的作用越小，策略要定期回看。

## 相关阅读与工具

- 想知道 Copilot 服务当前是否正常，可以看 cdnping 的 [Copilot 状态页](/down/copilot)，官方更新则可以在 [官网动态](/changes) 查看。
- Copilot 近期的变化：[GitHub Copilot HydraFusion 和新出的 Max 选项是什么](/blog/github-copilot-hydrafusion-max)，以及 [GitHub Copilot 11 月 16 日下线三款模型](/blog/github-copilot-model-deprecation-nov-16)。
- 如果你的 Agent 会调用第三方 API，建议同时读 [AI API 数据隐私怎么判断](/blog/ai-api-data-privacy-policy) 和 [Claude API 中转靠谱吗](/blog/is-claude-api-relay-safe)，了解数据流出你机器之后的风险。
- 工具连不上时，可以参考 [Claude Code 连接超时和报错怎么排查](/blog/claude-code-connection-troubleshooting) 的分层检查思路。

## 参考来源

- [Local sandboxing for GitHub Copilot now generally available（GitHub Changelog，2026-10-07）](https://github.blog/changelog/2026-10-07-local-sandboxing-for-github-copilot-now-generally-available/)
- [GitHub Copilot weekly releases: October 5（GitHub Changelog）](https://github.blog/changelog/2026-10-09-github-copilot-weekly-releases-october-5/)
- [About cloud and local sandboxes for GitHub Copilot（GitHub Docs）](https://docs.github.com/copilot/concepts/security-governance-and-network-settings/about-cloud-and-local-sandboxes)
- [microsoft/mxc（GitHub）](https://github.com/microsoft/mxc)
