摘要： 企业选择 Coding Agent Sandbox，不能只问“有没有沙箱”，而要同时比较运行位置、宿主机隔离、可写目录、网络出口、Secrets 生命周期、人工审批、策略集中管理和审计闭环。Codex、Claude Code 与 GitHub Copilot 都已提供本地或云端隔离能力，但适用场景不同：Codex 的“技术边界＋审批策略”分层最直观，适合需要精细控制终端 Agent 的团队；Claude Code 的权限规则、网络隔离与企业代理适配较灵活，适合本地开发环境治理；GitHub Copilot cloud agent 以临时 GitHub Actions 环境、仓库授权、Agent Firewall 和 PR 工作流见长，适合代码托管与治理高度集中在 GitHub 的企业。本文给出完整对比、选型矩阵和落地检查清单。
核心结论
没有一个 Sandbox 在所有企业场景中绝对最好。若企业要求最清晰的本地文件/网络边界与逐项审批，优先评估 Codex；若需要丰富的本地权限规则、企业代理和 Claude Code 工作流，优先评估 Claude Code；若要求任务在云端隔离环境执行并天然进入 Branch、Commit、PR 和组织策略，GitHub Copilot cloud agent 更合适。
- Codex： 沙箱决定“技术上能做什么”，Approval Policy 决定“何时必须询问”，两层职责清晰；云端采用隔离容器，并把依赖安装阶段与默认离线的 Agent 阶段分开。
- Claude Code： Manual 模式默认只读，文件修改与危险 Bash 操作需批准；内置 Bash Sandbox 支持文件系统与网络隔离，并能用用户、项目和组织级规则治理。
- GitHub Copilot： 本地和云端 Sandbox 均已提供；Cloud Agent 运行在临时 GitHub Actions 环境中，可按仓库开放、配置 Agent Firewall，并通过 Branch/PR 保留过程证据。
- 企业选择重点： 本地终端自治优先看 Codex/Claude Code；GitHub 原生异步任务优先看 Copilot Cloud Agent；最高敏感场景应叠加容器、短期凭据、默认拒绝网络和独立 CI。
- 共同底线： 沙箱不能替代代码审查、Prompt Injection 防护、Secrets 管理和生产权限隔离，任何自动合并、部署、删库、付款或权限修改都必须设置人工 Gate。
先澄清：Sandbox 比较的不是一个产品按钮
同一款 Coding Agent 可能有本地 CLI、IDE 插件、桌面应用、云端任务和自托管 Runner。它们的信任边界完全不同。如果把“本地 Agent Mode”和“云端临时容器”放在同一行比较，结论会失真。
企业应先确定四个边界：
- 代码在哪里执行： 开发者电脑、企业工作站、容器、厂商云或自托管 Runner。
- Agent 能访问什么： 当前仓库、额外目录、宿主机进程、Docker Socket、网络和 MCP。
- 身份从哪里来： 本地环境变量、系统钥匙串、GitHub Token、云端 Secret 或短期 OIDC。
- 变更如何落地： 直接修改工作区、创建临时分支、推送 Commit、打开 PR 或触发部署。
本文采用以下主要口径：Codex CLI/IDE 与 Codex cloud；Claude Code 本地 Manual/Sandbox 与 cloud session；GitHub Copilot 本地 Sandbox 与 Copilot cloud agent。有关更广泛的 Agent 安全方案，可参考 AI Stack Nav：Coding Agent 安全专题。
三家 Sandbox 总体对比
| 维度 | Codex | Claude Code | GitHub Copilot |
|---|---|---|---|
| 本地默认思路 | Sandbox Mode 与 Approval Policy 分层 | Manual 默认只读，按工具/命令授权 | CLI/IDE 权限提示；本地 Sandbox 可启用 |
| 文件系统边界 | 可限制工作区写入，并配置额外 writable roots | 启动目录及子目录为主要写边界，可配置 additional directories 与 denyRead | 本地 Sandbox 限制文件、网络与系统能力；具体随客户端与策略变化 |
| 网络策略 | 本地可按沙箱/审批控制；Cloud Agent 阶段默认离线，环境可显式开网 | Bash Sandbox 支持网络隔离；curl/wget 等默认不自动批准，可配代理/mTLS | Cloud Agent 可配置 Agent Firewall 外部主机与 URL；本地 Sandbox 限网 |
| 云端隔离 | OpenAI 管理的隔离容器 | 新鲜仓库克隆的 cloud environment，可用自托管环境 | 临时 GitHub Actions-powered environment |
| Secrets 设计 | Cloud setup 阶段可用 Secret，Agent 阶段前移除 | 凭据可由本地安全存储或云环境提供，需按环境治理 | GitHub 环境、Token 与 Runner 策略结合，宜用最小权限和短期凭据 |
| 审批机制 | Approval Policy、规则和 Sandbox escalation | Manual、Allow/Ask/Deny、Auto classifier、组织策略 | Permission prompt、组织策略、仓库授权、PR 审批 |
| 企业集中治理 | 组织约束、配置文件与审批策略 | Managed settings、项目规则、企业代理/CA/mTLS | Enterprise/Organization policy、仓库白名单、Firewall、MDM |
| 审计落点 | 会话、命令、审批和代码变更 | 会话、权限请求、Hooks 与代码变更 | Commit、Agent 日志、Branch、PR 与 GitHub 审计链 |
| 最适合 | 精细控制本地与云端开发 Agent | 本地终端权限和企业网络治理 | GitHub 原生异步 Agent 与 PR 流程 |
这张表是架构选型结论，不代表官方安全评级。三家的具体能力还受版本、操作系统、计划、组织策略和运行入口影响，应以实际控制台及官方文档为准。
Codex：沙箱与审批两层分离最清楚
Codex 的突出特点是明确区分 Sandbox Mode 与 Approval Policy。前者决定命令在技术上可以写哪些位置、是否可以访问网络；后者决定遇到越界操作、网络请求或不受信任命令时，是否必须暂停并请求批准。
典型的 workspace-write 模式允许 Codex 在工作目录读取、编辑并运行命令，但不等于获得整个主机权限。需要跨目录工作时，可以增加 writable roots，而不是直接取消沙箱。对特定命令可使用规则设置 Allow、Prompt 或 Forbid，适合把例外收敛到明确命令前缀。
Codex cloud 使用 OpenAI 管理的隔离容器，无法访问宿主机或无关数据。官方文档描述了两阶段模型：Setup 阶段可以联网安装指定依赖；Agent 阶段默认离线，除非为环境显式打开互联网访问。云环境 Secret 只在 Setup 阶段可用，并在 Agent 阶段前移除。这对防止模型在写代码期间直接读取长期凭据很有价值。
Codex 的企业优势包括：
- 技术隔离与审批体验解耦，策略容易解释和审计；
- 可把自动允许限制在工作区内，越界操作继续请求批准；
- 云端 Setup/Agent 分阶段，便于收紧依赖安装后的网络与 Secret；
- 规则可对特殊工具、网络和命令设置更细例外。
局限也很明确：如果用户选择过宽的可写根目录、长期允许危险命令，或者给工作区挂载 Docker Socket、云凭据和生产配置，沙箱边界会被人为扩大。自动审批 Reviewer 也不会改变底层 Sandbox Boundary，它只负责审查到达边界的请求。
Claude Code：权限规则与企业网络适配更灵活
Claude Code 在 Manual 模式下以只读权限启动。需要编辑文件、运行测试或执行可能修改系统的 Bash 命令时，会请求用户批准。它可以在当前工作目录及子目录内建立主要写边界，访问父目录或范围外文件时继续提示。
内置 Bash Sandbox 为命令提供文件系统和网络隔离。Claude Code 还提供 Allow、Ask、Deny 权限规则，可分别放到用户、共享项目和 Managed Settings 范围。共享项目设置能够随仓库提交，组织则可通过更高优先级规则限制开发者自行放宽权限。
网络方面，curl、wget 等获取外部内容的命令在 Manual 模式下不会默认自动通过；需要强制执行而不是依赖命令文本匹配时，应使用 Sandbox 网络隔离。企业还可配置 HTTP/HTTPS 代理、自定义 CA 和 mTLS，这对必须经过安全代理、出站审计或私有证书链的组织很实用。
Claude Code 的优势包括：
- 本地 Manual 模式从只读开始，交互式权限模型直观；
- 用户、项目、组织多层配置适合不同团队共享规则；
- 企业代理、CA、mTLS 与网络隔离能力适合受管网络；
- 首次代码库与新 MCP Server 需要信任确认，并提供 Prompt Injection 防护说明。
需要注意：非交互式 -p 模式会关闭部分首次信任验证；一旦团队在规则中允许过宽 Bash 模式，字符串匹配也可能遗漏组合命令、解释器或间接网络访问。因此关键限制要由真正的文件/网络沙箱执行，而不是只依赖权限提示。
GitHub Copilot：云端仓库与 PR 治理最完整
GitHub Copilot 需要区分本地 Agent 与 Cloud Agent。本地 IDE/CLI 直接面对开发者环境，权限提示用于修改文件、执行命令或访问当前目录之外的内容；2026 年推出的本地 Sandbox 可限制文件系统、网络和系统能力，并使用 /sandbox enable 在支持的会话中启用。官方说明该方案基于 Microsoft MXC，并支持 macOS、Linux 和 Windows，企业可借助 Intune 等 MDM 中央配置。
Copilot cloud agent 则在 GitHub Actions 驱动的临时开发环境中运行。它研究仓库、创建计划、修改分支、运行测试，并让开发者查看 Diff、迭代或创建 PR。所有步骤围绕 GitHub 仓库、Commit 和日志发生，因此天然适合已有分支保护、CODEOWNERS、Required Checks 与安全审查的团队。
企业管理员可以选择允许 Cloud Agent 的仓库，并配置 Agent Firewall 可访问的外部主机和 URL。对 Copilot Business/Enterprise 组织成员，Cloud Agent 和第三方 MCP Server 默认关闭，需要管理员显式启用。管理员还可以单独控制自动化任务，避免定时或事件触发的 Agent 在没有额外治理时扩散。
Copilot 的主要优势是：
- 云端任务不直接运行在开发者电脑上；
- 临时环境与分支、Commit、PR、日志形成统一证据链；
- 仓库访问范围、Cloud Agent、MCP 和自动化可以由组织策略控制；
- Agent Firewall 能把网络出口限制在批准主机与 URL；
- GitHub 原生 CODEOWNERS、Rulesets 和 Actions Checks 可直接作为合并 Gate。
局限是其治理优势高度依赖 GitHub 生态。如果代码不托管在 GitHub，或企业使用复杂内网依赖、自定义构建集群和非 GitHub 审批流，接入成本会提高。本地 Sandbox 与部分跨平台能力仍可能处于 Preview，需核对客户端版本和组织政策。
哪个方案的网络隔离更适合企业？
网络是 Coding Agent 最容易被低估的风险面。只要 Agent 同时能读取源码或 Secrets 并访问未知公网，Prompt Injection 就可能变成数据外传。
Codex cloud 的 Setup/Agent 两阶段适合“先联网装依赖、再离线写代码”；Claude Code 适合通过企业代理、CA、mTLS 和 Sandbox 网络规则接入受管内网；Copilot cloud agent 适合用组织级 Agent Firewall 维护外部 Host/URL 白名单。
企业不应采用“所有 HTTPS 都允许”的策略，推荐按任务建立最小出口：
network_policy:
default: deny
allow:
- host: registry.npmjs.org
methods: [GET]
- host: pypi.org
methods: [GET]
- host: api.github.com
methods: [GET]
deny_private_ranges: true
log_dns_and_http_metadata: true
max_request_seconds: 30
这是通用参考策略，不是三家产品的原生配置格式。包管理器还可能跳转 CDN 或镜像，白名单需要通过测试完善，但不能因此永久开放任意网络。
Secrets、MCP 与 Docker Socket 怎么处理？
沙箱最常见的失败不是内核漏洞，而是企业主动把高权限资源挂进去。以下对象应默认视为高风险：
~/.ssh、云厂商凭据目录和生产.env；- Docker Socket 或宿主机容器管理接口；
- 可写的 Kubernetes 配置和集群管理员 Token；
- 拥有组织级权限的 GitHub PAT；
- 可修改工单、数据库、云资源的 MCP Server；
- 浏览器登录态与本地密码管理器导出的凭据。
正确做法是为每次任务签发短期、最小权限身份，只挂载必要目录，并把 MCP 工具按只读、可写、破坏性操作分级。删除数据、修改权限、创建发布、发送外部消息和生产部署必须在工具执行前重新确认。
更多 MCP 安全策略可以查看 AI Stack Nav：MCP 权限与安全专题。
企业 Sandbox 选型评分矩阵
| 企业场景 | 推荐优先级 | 原因 | 必须补充的控制 |
|---|---|---|---|
| 本地终端精细审批 | Codex / Claude Code | 文件、网络、命令审批可细化 | MDM、统一规则、最小凭据 |
| GitHub Issue 到 PR | GitHub Copilot cloud agent | 临时环境与 PR 治理原生衔接 | Firewall、Rulesets、CODEOWNERS |
| 先装依赖后离线开发 | Codex cloud | Setup 与 Agent 阶段分离 | 固定依赖、制品校验 |
| 企业代理、私有 CA、mTLS | Claude Code | 官方支持受管网络配置 | 出站代理审计、DLP |
| 多操作系统统一本地隔离 | Copilot local sandbox | MXC 跨平台与 MDM 路线 | 核对 Preview 与客户端覆盖 |
| 高敏内网源码 | 自托管隔离层＋任一 Agent | 厂商内置沙箱不足以覆盖全部合规 | VDI/容器、无公网、短期身份 |
| 自动批量任务 | Copilot cloud / Codex cloud | 与本地工作站解耦 | 配额、并发、超时、人工 Gate |
以上是编辑选型建议，并非官方排名。实际采购前应在相同仓库、相同任务与相同网络条件下做 Proof of Concept。
十二步企业落地流程
- 分类代码与数据。 按公开、内部、机密、受监管划分仓库，不同级别采用不同执行环境。
- 确定运行位置。 明确哪些任务允许本地执行，哪些必须云端临时环境或自托管 Runner。
- 默认拒绝。 初始策略设为工作区只读或最小写入、网络拒绝、无生产 Secrets。
- 建立目录边界。 只允许当前仓库和显式临时目录，禁止 Home、SSH、凭据与系统目录。
- 建立网络白名单。 仅开放必要包仓库、源码 API 和内部服务，记录 DNS 与连接元数据。
- 分级命令。 读取、构建、测试可自动；安装、联网、跨目录需审批；删除、部署和权限修改必须人工批准。
- 治理 MCP。 只允许登记服务器，固定版本，限制 Scope，并对副作用工具增加二次确认。
- 使用短期身份。 优先 OIDC、临时 Token 和细粒度仓库权限，避免长期管理员 PAT。
- 建立可信 CI。 Agent 自己运行的测试只作参考，PR Gate 由独立 Runner 重新执行。
- 设置资源上限。 限制 CPU、内存、进程、磁盘、超时、重试次数与并发，防止无限循环和成本失控。
- 保留审计证据。 记录 Prompt、工具调用、审批、网络、Diff、测试结果、身份和最终合并人。
- 演练回滚。 定期测试禁用 Agent、撤销 Token、关闭网络、回滚 PR 和隔离受影响 Runner。
建议的审批分级
建议把操作分为四级：
- L0 自动允许： 读取仓库文件、列目录、查看 Git 状态、运行无副作用静态分析。
- L1 工作区自动： 在当前分支编辑文件、运行受信任测试、写入临时目录。
- L2 单人批准： 安装依赖、访问白名单网络、调用可写 MCP、跨目录读取。
- L3 双人或安全审批： 删除大量文件、修改权限、生产部署、发布包、访问客户数据、写生产数据库。
失败后的 Retry 也要分级。只读查询可以有限自动重试；创建 PR、发送消息和修改外部系统应使用幂等键；付款、删库、权限变更不应由 Agent 自动重试。超时必须终止子进程并回收临时环境，而不是让任务在后台继续运行。
Prompt Injection 与“批准疲劳”仍是共同弱点
Sandbox 保护的是执行边界，不能证明模型计划正确。Agent 读取恶意 README、Issue、网页、依赖说明或测试日志后，仍可能被诱导请求联网、读取敏感文件或执行危险命令。
如果用户连续看到几十次弹窗，就可能习惯性批准。因此企业策略应让常见安全操作在沙箱内自动执行，把提示集中在真正越界的少数动作；审批界面要显示命令、工作目录、网络目标、将读取的 Secret 和预期副作用，而不是只显示“是否允许”。
三家都提供不同形式的 Prompt Injection 或权限防护，但任何模型分类器都不能替代强制隔离。最可靠的顺序仍是：默认拒绝网络与敏感目录；模型提出请求；策略引擎进行确定性检查；必要时人工确认；执行后写审计日志。
成本、迁移与运维注意事项
沙箱成本不仅是订阅费用，还包括云 Runner、构建缓存、制品存储、网络代理、日志平台和安全运营。云端 Agent 隔离更强，但大型仓库的依赖安装和测试可能消耗更多时间；本地 Agent 反馈快，却需要统一管理开发者终端与规则。
不要把整家公司一次性切换。可以先选择三类任务：文档更新、单元测试补齐和低风险 Bug 修复，在相同仓库上对三家方案记录任务成功率、人工审批次数、越界请求、网络访问、执行时间、返工率和每个有效 PR 的总成本。
若要迁移，应把安全政策保存在厂商无关的控制清单中，而不是只写进某个工具配置。至少保留：允许目录、允许域名、命令等级、MCP 清单、Secrets Scope、超时、审计字段和合并 Gate。这样更换 Agent 时只需转换适配层。
最终选型建议
如果企业主要需要本地或 IDE 内的高自治 Agent，并希望把“能不能做”与“要不要问”明确拆开，Codex 的模型最容易建立统一安全语言。若团队高度依赖 Claude Code、需要细粒度 Allow/Ask/Deny、企业代理与自定义证书，Claude Code 更顺手。若研发资产、Issue、Actions 和 PR 都在 GitHub，Copilot Cloud Agent 的端到端治理链最短。
对金融、政务、医疗、核心生产代码等高敏场景，不应直接根据品牌选择。应把三者都运行在企业控制的隔离层内，使用无公网或严格白名单、短期身份、只读代码镜像和独立 PR Gate。此时厂商 Sandbox 是第二层防护，不是唯一边界。
FAQ
Codex、Claude Code 和 Copilot 哪个 Sandbox 最安全？
没有脱离部署场景的绝对答案。Codex 的沙箱/审批分层清晰，Claude Code 的本地权限和企业网络适配细，Copilot Cloud Agent 的 GitHub 原生隔离与 PR 审计更完整。高敏企业还应叠加自有容器或 VDI。
本地 Sandbox 能阻止 Agent 读取整个电脑吗？
正确配置时可以显著限制访问，但要检查额外目录、Home 目录、符号链接、工具继承权限和 MCP。任何过宽 Allow 规则都会扩大边界。
云端 Sandbox 一定比本地更安全吗？
云端临时环境通常能隔离开发者宿主机，但会引入源码上传、云端凭据、第三方托管和网络出口问题。安全性取决于数据分类和策略，而不是“云端”两个字。
GitHub Copilot Cloud Agent 会直接修改默认分支吗？
官方工作流以独立分支、Diff、Commit 和可选 PR 为核心。企业仍应使用 Rulesets、Required Checks 和 CODEOWNERS 禁止未审查变更进入默认分支。
Claude Code Manual 模式是否等于完整沙箱？
不等于。Manual 模式主要是权限与确认机制；真正的文件系统和网络强制隔离需要启用并正确配置 Bash Sandbox，关键限制不能只靠提示。
Codex Cloud 为什么把 Setup 和 Agent 分开？
这种设计允许 Setup 阶段联网安装依赖，并让 Agent 阶段默认离线；配置给云环境的 Secrets 在 Agent 阶段前移除，可降低写代码期间的凭据暴露面。
使用 Sandbox 后还需要人工代码审查吗？
需要。Sandbox 限制 Agent 能触碰的资源，却不能保证补丁符合业务逻辑、没有后门或不会破坏数据。合并前仍需可信 CI 与人工审查。
MCP Server 是否会绕过 Sandbox？
有可能形成独立权限通道。MCP 工具运行在哪里、持有什么 Token、是否联网以及是否受同一审批策略控制都要单独核对，不能假设主进程沙箱自动覆盖 MCP。
企业试点应该从什么任务开始？
从文档、测试和低风险 Bug 修复开始，避免首次试点就涉及部署、数据库、账户权限或客户数据。用真实指标验证后再扩大范围。
事实依据与来源
- OpenAI 官方事实： Codex 将 Sandbox Mode 与 Approval Policy 作为两层控制；Codex cloud 使用隔离容器，并采用 Setup 可联网、Agent 默认离线的两阶段模式，云环境 Secrets 在 Agent 阶段前移除。
- Anthropic 官方事实： Claude Code Manual 模式默认只读；Bash Sandbox 支持文件系统和网络隔离；权限可以通过用户、项目和组织范围配置，并支持企业代理、自定义 CA 与 mTLS。
- GitHub 官方事实： Copilot 本地和云端 Sandbox 于 2026 年进入 Public Preview；Cloud Agent 使用临时 GitHub Actions 环境，组织可限制仓库访问并配置 Agent Firewall。
- 编辑判断： “Codex 最适合精细审批、Claude Code 最适合本地企业网络、Copilot 最适合 GitHub 原生治理”是基于官方能力的场景化判断，不是厂商安全评级。
- 实施建议： 文中的四级审批、默认拒绝网络、双人审批和十二步流程属于企业落地建议。
- 待实测项目： 不同操作系统、客户端版本、自托管 Runner、复杂 Monorepo 和企业代理下的实际隔离效果，应由企业 PoC 验证。
参考来源
- OpenAI Codex：Agent approvals & security
- OpenAI Codex：Sandbox
- Anthropic：Claude Code Security
- Anthropic：Claude Code Settings
- Anthropic：Enterprise network configuration
- GitHub：Cloud and local sandboxes for Copilot
- GitHub Docs：About Copilot cloud agent
- GitHub Docs：Managing Copilot cloud agent for organizations
- GitHub Docs：Responsible use of Copilot Agents
内容核验日期：2026 年 9 月 25 日
工具选型与提示词资料
适合阅读工具评测、工具推荐、对比测评类文章后继续转化。
