Docker Sandbox

核心用法

Docker Sandbox 是 Docker Desktop 4.49+ 提供的VM级隔离执行环境，通过轻量级虚拟机实现 agent 与宿主系统的彻底隔离。核心工作流三步：创建沙箱（docker sandbox create）→ 执行命令（docker sandbox exec）或直接运行 agent（docker sandbox run）→ 清理销毁（docker sandbox rm）。支持 Claude、Codex、Copilot、Gemini、Kiro 等主流 AI agent，工作目录通过 virtiofs 高性能挂载，保持与宿主路径结构一致。

显著优点

1. 真正的硬件级隔离
不同于容器隔离，每个沙箱运行在独立轻量 VM 中，文件系统、网络栈完全隔离，即使沙箱内内核漏洞也无法逃逸至宿主。

2. 精细化网络管控
内置网络代理支持白名单/黑名单双模式：--policy deny 默认拒绝所有出站，仅放行指定域名；支持 CIDR 级别的 IP 封锁、绕过代理直连配置，以及完整的网络活动日志审计。

3. 即开即用的开发环境
预装 Node.js LTS、Git、Python、curl 及 npm 全局目录，Docker-in-Docker 支持（/run/docker.sock 挂载），满足绝大多数开发场景无需额外配置。

4. 多 agent 统一接口
单一命令格式适配不同 AI 提供商的 agent，降低团队多工具切换成本。

5. 可持久化与模板化
支持 save 命令将配置好的沙箱保存为团队共享模板，实现环境 reproducibility。

潜在缺点与局限性

• 版本门槛严格：必须 Docker Desktop 4.49+，旧版本用户需升级
• VM 启动开销：相比原生容器有额外启动时间（秒级），不适合高频短任务
• Node.js fetch 代理不兼容：原生 fetch 忽略 HTTP_PROXY 环境变量，需额外 require hook 处理（文档已提供方案）
• Windows 路径转换陷阱：Git Bash/MSYS2 会自动转换 Unix 路径，需设置 MSYS_NO_PATHCONV=1
• 资源占用：每个沙箱独立 VM，大量并行沙箱将显著消耗内存

适合人群

• 需要安全测试不可信 npm 包的安全研究人员与开发者
• 运行外部来源代码（如 AI 生成的脚本）的 AI 应用开发者
• 需要网络受限环境执行敏感操作的合规团队
• 追求可复现环境的 MLOps / DevOps 工程师

常规风险

沙箱本身不消除代码逻辑风险（如删除挂载目录内的文件），仅隔离系统层面影响。建议配合 --policy deny 网络策略使用，并定期审查 docker sandbox network log。删除沙箱为不可逆操作（rm 直接销毁 VM），重要数据需确保已同步出沙箱。

核心用法

docker-sandbox 技能是 Docker Desktop 官方沙箱功能的完整使用指南，旨在为 AI 代理提供安全、隔离的运行时环境。该技能围绕 docker sandbox CLI 命令展开，详细介绍了如何创建、管理、监控和销毁沙箱化虚拟机。其核心用途包括探索不受信任的软件包、安全执行外部代码、隔离具有潜在破坏性的操作，以及为代理工作负载建立可再现的实验环境。技能特别强调了网络代理控制，允许用户设置默认拒绝的白名单策略，精确控制沙箱的出站网络活动。此外，它还提供了持久化开发环境设置、自定义容器模板以及团队共享模板等高级功能，满足了从一次性测试到团队协作的多种场景需求。

显著优点

1. 硬件级安全隔离：每个沙箱都运行在独立的轻量级虚拟机中，通过 virtiofs 挂载工作区，提供了文件系统、网络和进程的全面隔离，远超传统容器隔离水平。
2. 精细的网络控制：内置网络代理功能强大，支持基于域名、IP 段的精细控制，并提供默认“拒绝所有”的策略，随后按需添加白名单，最大化安全边界。
3. 多 Agent 原生支持：开箱即用地支持 Claude、Codex、Copilot、Gemini、Kiro 等多种主流 AI 代理，无需额外配置即可为不同代理创建隔离环境。
4. 开发生态集成度高：沙箱内预装 Node.js、Git、Python 等标准开发工具，支持 Docker-in-Docker，并自动配置代理环境变量，降低了环境搭建成本。
5. 官方背书与零代码风险：由 Docker Inc. 官方维护，本身为纯 Markdown 文档型技能，不含任何可执行代码或第三方依赖，从源头杜绝了技能本身引入安全风险的可能。

潜在缺点或局限性

1. 系统依赖性强：该技能高度依赖于 Docker Desktop 4.49 及以上版本，要求用户必须安装指定版本，这对使用旧版本或未安装 Docker 的用户构成了前置门槛。
2. 性能开销：每个沙箱都是一个完整的轻量级虚拟机，其启动速度、资源占用（内存、CPU）将显著高于简单的容器或进程内隔离方案，可能不适用于对启动延迟极敏感的场景。
3. Node.js 代理兼容性问题：技能明确指出 Node.js 的内置 fetch (基于 undici) 默认不遵守 HTTP_PROXY 环境变量，需要用户手动引入代理修复脚本，这增加了使用复杂性并可能成为网络控制的薄弱点。
4. 操作系统路径复杂性：在 Windows 系统上，宿主机路径与沙箱内路径的映射关系不同，且 Git Bash/MSYS2 环境存在路径自动转换问题，需要额外的配置指令（如 MSYS_NO_PATHCONV=1）来规避。

适合的目标群体

• AI 代理安全使用者：需要对代理执行外部代码、安装未知包、访问网络等行为进行严格审计和控制的开发者或安全工程师。
• 开源软件审查者：需要在一个完全隔离的环境中测试、调试或逆向分析来自互联网的陌生或不受信任的软件包的开发人员。
• DevOps/SRE 工程师：需要为自动化脚本、CI/CD 流程或一次性任务快速搭建和销毁干净、可复现的测试环境的工程师。
• 教育与研究人员：希望在标准化、不可变的环境中运行实验代码，且需要严格控制代码网络访问权限的学生或科研人员。
• 多项目并行开发者：需要在不同项目间快速切换，并为每个项目维护独立、洁净开发环境的全栈开发者。

使用风险提示

1. 资源争抢风险：同时运行多个沙箱会大量消耗宿主机的内存和 CPU，如果资源不足，可能导致系统响应变慢，甚至影响沙箱的稳定性。建议为每个沙箱清晰规划资源使用上限。
2. 网络策略配置错误风险：复杂的网络代理规则（例如，错误的默认策略或遗漏关键白名单域名）可能导致沙箱内的代理无法正常工作，如无法访问必要的 API 端点或下载依赖。配置完成后，务必进行网络连通性测试。
3. 数据持久化误判风险：沙箱被设计为可随手销毁的“牲畜”而非“宠物”。如果用户错误地认为沙箱内数据会自动持久化，在未使用 docker sandbox save 模板化状态或挂载外部卷的情况下执行 docker sandbox rm，将导致工作状态和数据永久丢失。
4. Docker 版本碎片化风险：技能高度依赖 docker sandbox 插件，如果团队或环境中 Docker 版本不统一或升级滞后，将导致无法使用此功能，造成工作流分裂。强有力的团队 IT 策略是保障其可用性的关键。
5. 隔离逃逸的理论风险：尽管基于 VM 的隔离比容器更强，但历史上任何虚拟化技术都存在出现逃逸漏洞的可能。对于处理顶级机密或面对高级持续性威胁（APT）的场景，建议仍将此沙箱视为安全深度防御中的一层，而非唯一的救命稻草。