让编码智能体在陌生仓库里干活正在变成日常：接手遗留项目、跑开源示例、审别人的 PR，Agent 需要执行 npm install、跑构建、执行测试。问题也随之而来——你给 Agent 的每一条 shell 权限，同时也是仓库里未知代码的权限。npm 包投毒、恶意 postinstall 脚本、被注入的构建文件，都指望你「无脑放行」。GitHub Copilot CLI 从 10 月初的 v1.0.92/v1.0.93 起把命令沙箱开放给全部用户：会话里 /sandbox enable 或启动时加 --sandbox，Agent 的 shell 命令就被关进限制文件系统、网络与系统能力的本地沙箱里执行；配合凭证隔离（GITHUB_TOKEN 默认不再透传给沙箱内命令）与企业级的 permissions.limitTo 域边界，构成了一套「先上闸、再跑不可信代码」的完整防线。本篇按官方文档与版本日志，从安装升级到凭证验证完整走一遍。
先理解：审批模式挡不住恶意仓库
Copilot CLI 的默认安全模型是审批制：Agent 想跑可能改动或执行文件的命令（touch、chmod、node、sed 等）时会先问你，三个选项——本次允许、本会话内允许该工具、拒绝并给出不同指示。这套机制防的是「Agent 自作主张」，但防不住「你在被钓鱼式提示下点了允许」：恶意仓库可以把诱导内容写进 README、issues 甚至代码注释里，诱导你批准那条真正有害的命令。更危险的是 --allow-all-tools：官方文档原话警告，用了它 Copilot 拥有与你相同的文件访问权，可以不经批准运行任何你能跑的 shell 命令。沙箱的定位就是给自动审批兜底——在沙箱里，即便命令被放行，它能摸到的文件、网络与系统能力也被框死在你授权的范围内。审批管「Agent 想干什么」，沙箱管「干成了也出不了圈」，两层叠加才是跑不可信仓库的完整姿势。
沙箱不是银弹。官方文档在风险缓解一节给出的完整选项是：本地沙箱、云沙箱、或者干脆用权限收紧的虚拟机/容器/专用机器。沙箱显著压缩了爆炸半径，但「最小权限 + 不在主力机器跑高危任务」的原则不因此失效。
Step 1：升级到 v1.0.93+，顺手迁移设置文件
# 安装 / 升级 Copilot CLI
npm install -g @github/copilot
# 确认版本不低于 1.0.93
copilot --version命令沙箱在 v1.0.92 起灰度、v1.0.93（10 月 7 日）正式对全部用户开放，通过 /sandbox 与 --sandbox 两个入口使用。升级时注意一个设置迁移坑：从 v1.0.93 起，用户设置只从 ~/.copilot/settings.json 读取，留在 ~/.copilot/config.json 里的用户设置键会被忽略——升级后沙箱或权限行为「突然变了」，先检查你的配置写在哪个文件里。
Step 2：开启本地沙箱
# 方式一：进入会话后开启
copilot
> /sandbox enable
# 方式二：启动时直接带标志
copilot --sandbox
# 方式三：程序化调用同样适用（跑不可信仓库的推荐姿势）
copilot -p "Install dependencies and run the test suite" \
--sandbox --allow-tool='shell(npm)' --allow-tool='write'开启后，Agent 的 shell 命令会在受限环境里执行：文件系统访问被框进你授权的目录，网络默认受代理管控，系统能力按需申请。程序化调用（-p）跑批处理不可信仓库时，--sandbox 与细粒度的 --allow-tool 组合是最稳的搭配：只放行任务必需的工具，其余全部走审批或直接拒绝。
Step 3：配置网络白名单
沙箱默认管控网络出向请求，被代理拦截的目标会触发放行询问。需要常驻放行的目标（内部 registry、本地开发服务）写进网络白名单；v1.0.93 起 allowlist 支持 localhost 与 loopback 主机，跑本地依赖服务（数据库、mock server）不再需要反复点放行：
# 白名单思路示例（具体键名以当前版本文档为准）：
# - 允许访问公司内部 npm registry 域名
# - 允许 localhost / 127.0.0.1 的开发端口（v1.0.93+）
# - 其余目标保持「每次询问」或默认拒绝白名单按需最小化。每多放一个域，恶意代码的出网面就大一分。放行内部 registry 域名时确保走的是 HTTPS 且域名精确匹配；v1.0.93 还给企业用户加了 permissions.limitTo，把网络请求强制锁在托管域边界内——团队治理场景优先用它而不是散装白名单。
Step 4：验证凭证隔离
# 在沙箱会话里让 Agent 执行，验证环境变量隔离：
> 运行: echo ${GITHUB_TOKEN:0:8}...
# 预期：空或报未定义 —— 沙箱内命令默认拿不到你的 GITHUB_TOKEN
#（v1.0.92 起：除非你显式配置，否则沙箱不透传 ambient GITHUB_TOKEN）
# git 操作：沙箱内的 git 以掩码凭证认证，SSH remote 重写生效
# 私有仓库拉取走你的正常认证，但 token 不会以明文出现在命令环境里这一步是跑不可信仓库的核心防线：过去 Agent 能读到你 shell 里的 GITHUB_TOKEN，恶意脚本拿到它就能冒充你操作 GitHub。现在沙箱内命令默认看不到这个环境变量，需要时通过掩码凭证机制走 git 认证。如果你的任务确实需要 token（比如调 gh API），用显式配置放行，并在任务结束后撤销。
Step 5：用审批选项拧紧自动放行
# 允许一切但明确禁止高危命令（deny 优先级高于 allow）
copilot --allow-all-tools \
--deny-tool='shell(rm)' \
--deny-tool='shell(git push)'
# 更收敛的姿势：只放行测试所需，其余全审批
copilot --sandbox --allow-tool='write' \
--allow-tool='shell(npm test)' \
--allow-tool='shell(npm run build)'
# 连 MCP 工具也能按服务器/工具粒度控制
copilot --allow-tool='My-MCP-Server' \
--deny-tool='My-MCP-Server(tool_name)'规则记忆：--deny-tool 的优先级压过 --allow-all-tools 与 --allow-tool；shell 类规格支持到一级子命令（如 shell(git push) 只禁推送、放行其余 git）。跑不可信仓库时的推荐组合是 --sandbox + 白名单式 allow + 高危 deny（rm、git push、curl 外传等）。
Step 6：高危场景升级到云沙箱
# 云沙箱（public preview，行为可能变化）
copilot --cloud本地沙箱限制了 Agent 的能力边界，云沙箱则干脆不在你的机器上执行：整个 CLI 会话跑在 GitHub 托管的隔离环境里，适合「代码本身就不该碰我机器」的场景——分析可疑仓库、跑来路不明的构建脚本。云沙箱策略继承 Copilot 云端 Agent 的既有安全控制（防火墙规则等无需额外配置），并且支持会话状态保留、换机器续用与多任务并行。
云沙箱处于 public preview。官方文档明确标注「可能变化」，生产流程不要硬依赖其当前行为；同时注意云环境里跑的任务会接触仓库全部内容，涉及未公开代码与客户数据的仓库，先核对所在组织的合规要求。
常见问题 FAQ
Q：沙箱会让命令明显变慢吗？本地沙箱引入的是文件系统与网络的代理管控开销，常规开发命令（构建、测试、git）体感差异不大；遇到个别依赖特殊系统调用的工具（编译器缓存、容器运行时）可能需要额外放行，按提示处理即可。
Q：MCP 工具也在沙箱管控范围内吗？沙箱管的是 Agent 执行的 shell 命令与文件/网络访问；MCP 工具由各 Server 自行实现，权限走 --allow-tool/--deny-tool 的 MCP 服务器粒度控制。两者是并列的权限面，都要配。
Q：沙箱和虚拟机方案怎么选？日常不可信仓库，本地沙箱的便利性与安全性平衡最好；高度可疑目标（漏洞复现、恶意样本）直接上专用虚拟机或云沙箱，别在本机赌。