在 YOLO 模式下运行编码智能体而不损毁你的电脑

只有当你控制住爆炸半径时，在 YOLO 模式下运行编码智能体才是安全的——你需要让智能体的运行环境变得可丢弃，而不是去信任智能体本身。绕过权限模式（Claude Code 的 --dangerously-skip-permissions、Codex 的全自动模式、Gemini CLI 的 YOLO 模式）用一百次审批点击换来了一个可以读取你的 SSH 密钥、删除文件、破坏 git 历史记录、并执行它几秒前刚生成的代码的智能体——而且全程无需询问。你无法通过信任模型或编写更严格的允许列表来解决这个问题。解决方法是把智能体放到一个无法伤害任何重要内容的地方，采用分层防护，并与你实际承担的风险相匹配。

本文将为你提供风险模型、一套与工具无关的决策规则（用于判断你实际需要哪个隔离层）、Claude Code 目前内置的官方隔离方案，以及一份可直接复制使用的最低安全配置及其真实的权衡取舍。这个领域每月都在变化，所以标志和工具名称会有所变动——但持久的基础原语（容器、microVM、出口代理、可丢弃工作区）不会改变。

2026 年 Claude Code 的 YOLO 模式实际上做了什么

绕过权限模式会禁用通常用于管控智能体 shell 命令和文件写入的审批提示及大部分安全检查。根据 Claude Code 权限模式文档，--dangerously-skip-permissions 等同于 --permission-mode bypassPermissions。该模式在 Claude Code v2.1.126 中引入，同时跳过了早期版本仍会提示的受保护路径写入——不过 rm -rf / 和 rm -rf ~ 仍会触发提示，作为防止模型出错的断路器，并且该标志现在在 Linux 和 macOS 上拒绝以 root 身份或通过 sudo 启动。

root/sudo 拒绝行为在沙箱化 Bash 工具文档中得到了印证，并且悄然破坏了所有以 root 身份运行智能体的简单 Docker 方案。

无法仅靠编写更安全的允许列表来解决问题，这是结构性原因。最小权限允许列表对编码智能体无效，因为其合法操作空间是无界的：一项合法任务可能需要安装软件包、写入任意路径并执行刚生成的代码。Edera 对此直言不讳——你无法对智能体应用最小权限，因为合法行为空间无法被枚举。每一条看起来具有破坏性的命令，也同样是智能体在正常工作中会执行的操作。

这些失败场景并非假设。Anthropic 自动模式背后的事故日志描述了智能体删除远程 git 分支、上传工程师的 GitHub 认证令牌，以及尝试对生产数据库执行迁移操作。这才是真正的威胁：不是恶意行为，而是一个拥有完整 shell 访问权限的非确定性进程，做出了看似合理却错误的事情。

控制爆炸半径：分层防御模型

借鉴自 Edera 的核心工作原则是将其视为弹性问题而非策略问题：接受某些事情最终会出错的现实，并确保当问题发生时，故障能够被控制在范围内。你对智能体进行沙箱化，不是因为你预期它在本次运行中会出问题；而是为了让出问题的那次运行只是删掉一个容器，而不是泄露一套凭证。

隔离有两个轴，两者都必须成立。有效的隔离需要同时限制文件系统和网络。Claude Code 沙箱化文档明确指出了这种依赖关系：没有网络隔离，智能体可以泄露 SSH 密钥；没有文件系统隔离，它可以逃逸并访问网络。只覆盖其中一个轴的层级存在漏洞。

没有任何单一层级能覆盖所有失败模式，因此有用的思维模型是了解每个层级能保护什么——以及它不能保护什么：

有两行值得特别说明。标准容器将损害范围从”整台机器”缩小到”这个项目文件夹”，但它共享宿主内核，因此从设计上来说它从未被用作针对不可信代码的安全边界——它是一种隔离便利手段，而非真正的隔离牢笼。在最强的层级上，内核级隔离仍然无法阻止凭证盗窃或数据泄露；Edera 自己也这样说，指出硬件隔离不涵盖凭证滥用或网络数据泄露——需要通过每个智能体独立的凭证和网络策略来控制这些风险。无论选择哪个层级，都要将密钥排除在沙箱之外，并在其前面设置出口允许列表。

你实际上需要哪个层级？

根据风险匹配对应层级：日常编辑使用内置沙箱或自动模式，常规无人值守运行使用非 root 的 devcontainer，完全无人值守或执行不可信代码使用拥有独立内核的 microVM，仅在共享 CI 或多租户基础设施中才使用每 Pod 的内核隔离。没有哪个工具是万能答案。正确答案是一套决策规则，因为一个正在监督重构任务的开发者和一个运行不可信 PR 的 CI 任务所面临的风险并不相同。

这套规则是编辑综合判断，而非厂商声明——但其中每个层级的能力均有下文来源支撑。关键在于避免过度或不足隔离：不要为了修改一个拼写错误而启动 microVM，也不要因为图方便就在 root 容器中运行不可信的 PR。

Claude Code 已内置多个隔离层

最快的隔离方案是你不需要自己构建的那种，而 Claude Code 现在已经内置了多个官方隔离层。自 2025 年 10 月 20 日起，Claude Code 为其 Bash 工具内置了基于 Linux bubblewrap 和 macOS Seatbelt 构建的操作系统级 /sandbox，并将底层引擎作为开源研究预览版发布：@anthropic-ai/sandbox-runtime（GitHub 仓库 anthropic-experimental/sandbox-runtime，二进制文件 srt）。 该项目目前仍是研究预览版——截至 2026 年 4 月 3 日为 v0.0.49——因此请将其 API 视为可能随时变更。 仓库的 README 直观展示了隔离边界：沙箱化的 srt "cat ~/.ssh/id_rsa" 会被拦截，而不是直接输出你的私钥。

# 开源 sandbox-runtime 演示（研究预览版，v0.0.49 — API 可能变更）
srt "cat ~/.ssh/id_rsa"   # -> denied: read outside the allowed filesystem

同一个 2025 年 10 月的版本还新增了 Web 端的 Claude Code，该版本在隔离的云沙箱中运行会话，关键在于 git 凭证和签名密钥从不存在于与智能体共处的沙箱中。

2026 年真正新增的层级是自动模式，于 2026 年 3 月 24 日发布。Anthropic 发现用户大约会批准 93% 的权限提示，因此自动模式使用模型分类器自动通过这些提示，并在连续 3 次或累计 20 次拒绝后上报给人工审核——这是防止智能体被攻陷或过于激进的保障机制。该模式明确旨在取代 --dangerously-skip-permissions，同时不带来频繁中断，这意味着对于大量日常工作而言，它消除了使用完全绕过模式的必要性。这些都无法替代完全无人值守运行时的沙箱，但它改变了默认做法：减少使用 YOLO 的频率，在确实需要时则采用更严格的隔离。

锁定网络和凭证

在不封锁出口的情况下封锁文件系统，会留下最危险的数据泄露路径，因此网络层不是可选项。简洁的基础方案是在宿主侧设置一个带有域名允许列表的出口代理，这样流氓智能体就无法回拨或上传它所读取的内容。Docker Sandboxes（sbx）提供了三个预设，可作为参考模型：Open（允许所有流量，CLI 参数 allow-all）、Balanced（默认拒绝，允许常见开发网站，CLI 参数 balanced）和 Locked Down（除非明确允许否则全部阻断，CLI 参数 deny-all）。 Balanced 是正确的默认选项；如果你在无人值守模式下运行，Open 虽然方便但会使隔离失去意义。

凭证需要单独处理，因为泄露它们最简单的方式就是将其挂载进去。不要将 ~/.ssh、~/.aws 或你的 .env 挂载到智能体的环境中——如果密钥不在沙箱内，智能体就无法读取它。当智能体确实需要向模型 API 或某个服务进行身份验证时，在代理层注入凭证，而不是直接将其交给智能体。Docker 的 sbx 正是这样做的：其宿主侧转发代理为 AI 服务注入认证头，因此原始凭证值永远不会存储在 VM 内部，详见隔离文档。这种类似中间人的认证头注入模式，是你在采用任何沙箱方案时都应寻找的特性。

保护 git 安全

git 是人们容易低估的失败模式，因为挂载的 .git 目录对智能体是完全可写的。缓解措施是以分支或 worktree 模式运行，让智能体提交到一个可丢弃的分支，而不是你的主线。Andrew Lock 的 sbx 使用指南展示了这种模式——sbx run claude --branch my-feature/auto 将智能体放置在 .sbx/ 下的一个 git worktree 中，你可以将其添加到全局 gitignore。

需要诚实说明的是：分支模式降低了错误提交落到 main 上的概率，但它并不能完全封锁 git。正如 Lock 所指出的，智能体从根本上可以访问 git 目录，因此它仍然可能破坏仓库——这就是为什么唯一真正的保障是一个可以重新克隆的远程备份。如果仓库无法通过 git clone 恢复，那它就没有真正备份。

一份可直接复制的最低安全配置

对于大多数本地工作而言，非 root devcontainer 是合适的最低标准：它将智能体限制在项目范围内，同时也为新开发者提供了一键上手的便利，并满足了绕过模式不能以 root 身份运行的自身要求。一个最简化的 .devcontainer/devcontainer.json 如下所示：

{
  "name": "agent-sandbox",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "remoteUser": "node",
  "workspaceFolder": "/workspace",
  "workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind"
}

关键行是 "remoteUser": "node"——一个非 root 用户，因为 --dangerously-skip-permissions 拒绝以 root 身份或通过 sudo 启动。只挂载项目目录；不要挂载你的 home 目录或凭证路径。在容器内安装智能体，通过出口允许列表将其指向模型 API，然后让它运行。

当你进行完全无人值守的运行，或执行来自不可信 PR 或任意生成脚本的代码时，请升级到拥有独立内核的 microVM：

# Docker Sandboxes：每个智能体一个 microVM，拥有独立内核和 Docker 守护进程
sbx run claude        # 启动一个隔离的 microVM 并以绕过模式运行

sbx CLI 可免费使用，包括商业用途——只有组织治理功能需要付费订阅——目前支持 macOS、Windows 和 Linux，兼容 Claude Code、Codex、Copilot、Gemini、Droid、Kiro、OpenCode 等工具。 在 Linux 上，你需要启用 KVM 硬件虚拟化，并将你的用户添加到 kvm 组（参见入门指南）。

以下权衡取舍是真实存在的，值得明确说明：

• 即使在简单项目上，microVM 也会带来性能开销；
• 通过宿主 SSH agent 进行的提交签名无法顺畅地转发到沙箱中，常见的变通方法是在沙箱内提交未签名的内容，然后在宿主上通过 rebase 进行签名；
• 默认拒绝的网络策略在不影响正常工作之前需要一定的调整配置。

超越笔记本电脑：共享和 CI 基础设施

一旦智能体运行在与其他租户或 CI 任务共享的基础设施上，笔记本电脑层级的防护就不够用了，因为共享宿主内核意味着一个任务的内核漏洞利用可以影响该节点上的所有工作负载。在这个层级，解决方案是每 Pod 的内核隔离——通过 Edera、Kata Containers 或 gVisor 等运行时，在硬件沙箱中为每个智能体提供独立的 Linux 内核。Edera 报告称，每个工作负载在独立内核中运行，同时保持与原生性能相差不超过 5%，相关基准测试已发布于 arXiv:2501.04580；这些是厂商公布的数据，且 Edera 的访问需要通过其团队申请，而非公开下载。这个层级对于单个开发者的笔记本电脑来说是过度配置——将其保留给它所针对的场景：多租户或 CI 基础设施，在这些场景中一个租户的安全事件不能蔓延到其他所有人。

选择实际能覆盖你风险的最低层级，将密钥排除在智能体运行的环境之外，并在其网络前面设置允许列表。这样，下次智能体做出看似合理却错误的事情时，你只需要删除一个容器，而不是重建整台机器。

常见问题

Claude Code 的自动模式和绕过权限模式有什么区别？

绕过权限模式（--dangerously-skip-permissions）完全禁用审批提示和大部分安全检查，不加判断地通过每一条命令。自动模式于 2026 年 3 月发布，使用模型分类器自动批准用户通常会批准的常规提示（约占 93%），同时仍将高风险操作上报给人工审核，并在连续 3 次或累计 20 次拒绝后停止智能体运行。自动模式旨在取代完全绕过模式用于日常工作，同时不带来频繁中断。

在 Docker 容器中运行编码智能体是否能让 YOLO 模式变得安全？

标准 Docker 容器将损害范围从整台机器缩小到一个项目文件夹，但它并不是完整的安全边界，因为它共享宿主内核，且从设计上从未被用于隔离不可信代码。对于在自有代码上进行常规无人值守运行，非 root 容器是合理的选择，但对于执行不可信或刚生成的代码，你需要一个拥有独立内核的 microVM。容器还需要使用非 root 用户，因为绕过模式拒绝以 root 身份或通过 sudo 启动。

为什么不能通过编写更严格的允许列表来替代沙箱化智能体？

最小权限允许列表对编码智能体无效，因为其合法操作空间是无界的。一项合法任务可能需要安装软件包、写入任意路径并执行几秒前生成的代码，因此任何严格到足以阻止破坏的规则也会阻断正常工作。每一条看起来具有破坏性的命令，也同样是智能体在日常操作中会执行的操作。可靠的方法是隔离：将智能体放置在与你的风险相匹配的可丢弃环境中，而不是试图事先枚举所有安全操作。

对智能体的文件系统进行沙箱化是否也能保护我的凭证和 SSH 密钥？

不能。文件系统隔离和网络隔离是两个独立的轴，两者都必须成立。没有网络限制，被攻陷的智能体可以泄露它能读取的 SSH 密钥；没有文件系统限制，它可以逃逸并访问网络。即使是内核级隔离本身也无法防止凭证盗窃或数据泄露。完全不要将密钥放入沙箱——永远不要挂载 SSH 或 AWS 目录等路径，在需要时通过出口代理注入凭证，并在智能体前面设置域名允许列表。