T
traeai
登录
返回首页
Docker

编码代理恐怖故事：rm -rf ~/ 事件

6.5Score
编码代理恐怖故事：rm -rf ~/ 事件

TL;DR · AI 摘要

Docker 报告称，AI 编码代理在无隔离环境中执行危险命令（如 rm -rf ~/）导致数据丢失，强调需通过 Docker Sandboxes 等工具实现安全沙箱隔离，以防止此类事故。

核心要点

  • AI 编码代理在未隔离环境中执行 rm -rf ~/ 命令可导致用户主目录被彻底删除。
  • Docker 推出 Docker Sandboxes 产品，提供隔离环境以限制代理权限，防止误操作。
  • 建议开发者使用 Docker Scout 和 AI Governance 工具监控和治理代理行为，确保安全运行。

结构提纲

按章节快速跳转。

  1. §引言：AI 编码代理的安全风险

    AI 编码代理因缺乏权限控制可能执行破坏性命令，如 rm -rf ~/，造成严重数据损失。

  2. ·真实案例：rm -rf ~/ 事件

    某开发者使用编码代理时，代理自动执行 rm -rf ~/ 命令，导致整个用户目录被清空。

  3. ·根本原因：缺乏运行时隔离

    代理直接在宿主机上运行，未受限于沙箱或容器环境，导致高危命令被执行。

  4. ·解决方案：Docker Sandboxes

    Docker Sandboxes 提供隔离环境，限制代理访问系统资源，防止恶意或误操作。

  5. ›配套工具：AI Governance 与 Scout

    AI Governance 和 Docker Scout 可监控代理行为、审计命令执行，提升安全性。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • AI 编码代理安全风险
    • 风险案例
      • rm -rf ~/ 导致数据丢失
    • 根本原因
      • 无运行时隔离
      • 直接访问宿主机
    • 解决方案
      • Docker Sandboxes
      • AI Governance
      • Docker Scout

金句 / Highlights

值得收藏与分享的关键句。

  • AI 编码代理在无隔离环境下执行 rm -rf ~/ 命令，可能导致用户主目录被永久删除。

    — 第 2 段

    ⬇︎ 下载 PNG𝕏 分享到 X
  • Docker Sandboxes 为编码代理提供隔离运行环境，防止其访问敏感系统路径。

    — 第 4 段

    ⬇︎ 下载 PNG𝕏 分享到 X
  • Docker 推荐使用 AI Governance 和 Docker Scout 来监控和治理代理行为，避免安全漏洞。

    — 第 5 段

    ⬇︎ 下载 PNG𝕏 分享到 X
#AI Agents#Docker#安全#编码代理#沙箱
打开原文

编码代理恐怖故事：rm -rf ~/ 事件 | Docker

跳转至内容

Image 3

来自800多名开发者和领导者的AI代理现状洞察。下载您的副本

✕

[](https://www.docker.com/)

AI 与代理

应用安全

应用开发

开发者

获取最新的 Docker 新闻

  • 定价- [x] 年付 月付 Docker 个人版 $0 $0 面向需要构建和部署容器所需基础工具的独立开发者。 立即开始 立即开始 包含： #### Docker Desktop #### Docker Engine + Kubernetes #### Docker Hub #### Docker Scout #### Docker Debug 包含使用额度： #### 1 用户 #### 1 个启用 Docker Scout 的仓库* #### 每小时 100 次 Docker Hub 下载* #### 1 个私有 Docker Hub 仓库 #### Docker Build Cloud 和 Testcontainers Cloud 免费试用 Docker Pro $11 $9 每用户/每月 面向需要更高级功能和额外资源的独立专业人士。 立即购买 立即购买 包含： #### Docker Build Cloud #### Testcontainers Cloud #### 同步文件共享 #### Docker Scout 健康评分可见性 #### 5 个工作日支持响应 包含使用额度： #### 1 用户 #### 2 个启用 Docker Scout 的仓库 #### 无限次 Docker Hub 下载速率 #### 200 分钟 Docker Build Cloud 构建时间 #### 100 分钟 Testcontainers Cloud 运行时间 最受欢迎 Docker 团队版 $16 $15 每用户/每月 面向需要协作工具以提高团队效率的小型团队。 立即购买 立即购买 包含： #### 批量添加用户 #### 审计日志 #### Docker Hub 基于角色的访问控制 #### 2 个工作日支持响应 包含使用额度： #### 最多 100 用户 #### 无限个启用 Docker Scout 的仓库 #### 无限次 Docker Hub 下载速率 #### 无限个私有 Docker Hub 仓库 #### 500 分钟 Docker Build Cloud 构建时间 #### 500 分钟 Testcontainers Cloud 运行时间 #### 10 个组织访问令牌 #### 1 个 Docker Hub 组织 Docker 企业版 $24 $24 每用户/每月 面向希望获得强大安全、控制和合规功能的企业。 立即购买 立即购买 联系销售 联系销售 包含： #### 加固版 Docker Desktop #### 单点登录 (SSO) #### SCIM 用户配置 #### 镜像和注册表访问管理 #### Desktop Insights 仪表盘 #### 增强容器隔离 (ECI) #### 发票购买 #### 1 个工作日支持响应 包含使用额度： #### 无用户上限 #### 无限个启用 Docker Scout 的仓库 #### 无限次 Docker Hub 下载速率 #### 无限个私有 Docker Hub 仓库 #### 1,500 分钟 Docker Build Cloud 构建时间 #### 1,500 分钟 Testcontainers Cloud 运行时间 #### 100 个组织访问令牌 #### 无限个 Docker Hub 组织*** Image 4## Docker 加固镜像 (DHI)

为每个团队提供安全、精简的容器镜像，如需企业级功能可免费使用。开始免费试用

搜索

登录开始使用

切换菜单

编码代理恐怖故事：rm -rf ~/ 事件

发布于 2026 年 6 月 1 日

Image 5: Ajeet Raina 的头像照片

Ajeet Singh Raina

这是我们的“AI 编码代理恐怖故事”系列第二部分，深入探讨现实世界中的安全事件，揭示 AI 编码代理的漏洞，并介绍 Docker Sandbox 如何通过工作区范围的隔离，在执行层面上防止最严重的失败。

在本系列第一部分中，我们梳理了六类 AI 编码代理故障及其架构原因：代理以你的身份运行，操作你的文件系统，使用你的凭据，模型决策与 shell 执行之间没有任何隔离屏障。在第二部分中，我们将深入探讨整个生态系统中最具破坏性的故障模式：一个 AI 编码代理通过单条命令删除了开发者的整个主目录。

今日恐怖故事：那个抹掉 Mac 的波浪号

2025 年 12 月，一位 Reddit 用户（用户名 u/LovesWorkin）分享了一起当年最受关注的 AI 编码代理事件。他要求 Claude Code 清理一个旧仓库，Claude 执行了 rm -rf tests/ patches/ plan/ ~/，末尾的 ~/ 导致其整台 Mac 被清空。

这不是 CVE 漏洞，也不是复杂的攻击手段。这只是 AI 编码代理完全按照指令执行，但用户并未预料到这种后果，且架构上没有任何边界来阻止这一错误。

在本文中，你将了解：

  • 一个 rm -rf 命令末尾的单个斜杠如何抹除了一名开发者的整个 Mac
  • 为何存在 --dangerously-skip-permissions 标志，以及开发者为何仍持续使用它
  • 此事件与 GitHub-issue-#10077 Ubuntu 清除事件、Claude Cowork 家庭照片事件所共有的模式
  • Docker Sandboxes 如何在执行层面上防止此类故障的发生

为什么本系列重要

本系列中的每一篇“恐怖故事”都探讨了真实发生的事件，将实验室中的发现转化为生产环境中的灾难。这些不是假设性攻击，而是有明确受害者、截图命令日志，甚至在某些情况下厂商公开道歉的真实案例。我们的目标是揭示安全统计数据背后的人类影响，展示这些失败在实际中是如何展开的，并通过 Docker 的工作区限定执行模型，为保护你的 AI 开发基础设施提供具体指导。

故事始于每个开发者都曾做过的事：让代理清理旧仓库。

问题所在

2025年12月8日，一位名为 u/LovesWorkin 的开发者在 r/ClaudeAI 子版块发布了一篇 Reddit 主题帖（链接），标题直截了当：“Claude CLI 删除了我的整个主目录！我的整台 Mac 被清空了。”该帖子在数小时内获得超过 1,500 个点赞，随后被 Simon Willison 在 X 上转发（链接），并于12月16日被日本 Gigazine 报道（链接），成为2025年最受讨论的 AI 编码代理事件之一。

场景再普通不过。用户请求 Claude Code 清理旧仓库中的包。这是任何开发者都会不假思索地委托的任务。Claude 生成并执行了以下命令：

code
rm -rf tests/ patches/ plan/ ~/

表面上看，这是一个删除三个项目目录的命令。致命错误在于末尾的 ~/。在 Unix 中，~ 会扩展为用户的主目录，而 ~/ 加上斜杠表示“主目录内的所有内容”。结合 rm -rf —— 即递归无确认删除 —— 该命令瞬间清除了用户的整个主目录。

几秒钟内，开发者失去了：

  • 桌面、文档和下载文件夹
  • 包含系统上所有应用程序状态的 Library 文件夹
  • Keychain，导致所有应用认证失效，包括 Claude Code 自身也无法再与其后端通信
  • 多年的项目文件、家庭照片和工作成果
  • 所有数据存储在 SSD 上，当尝试恢复时，TRIM 已经将释放的块清零

无法恢复。正如开发者在原始帖子中所说：“它把我的整台 Mac 都炸了！到底发生了什么？”

Image 6: image2 2

_图注：一旦 AI 代理获得直接文件系统访问权限，“整理我的桌面”就可能变得灾难性。_

问题的规模

这并非孤立事件，而是某种模式的体现。

早在2025年10月21日，即 LovesWorkin 事件发生前几周，开发者 Mike Wolak 就向 Claude Code 仓库提交了 GitHub issue #10077。Wolak 的报告描述了类似故障发生在 Ubuntu/WSL2 环境下：Claude Code 执行了从根目录开始的 rm -rf，日志显示数千条针对 /bin、/boot 和 /etc 的“Permission denied”消息，因为代理试图删除其无权访问的文件。系统上所有用户拥有的文件全部消失。Anthropic 将此问题标记为 area:security 和 bug。Wolak 报告中最令人震惊的细节是：他并未使用 --dangerously-skip-permissions。Claude Code 的权限系统在用户批准前未能检测到该命令会破坏性展开。

两周后，2025年11月28日，GitHub issue #12637 记录了另一个变种。Claude Code 之前因失误创建了一个名为 ~ 的目录。之后，当代理尝试通过未加引号的 rm -rf ~ 清理该目录时，shell 先将 ~ 展开为用户的实际主目录，再传递给 rm。结果相同，但机制完全不同。代理找到了另一种摧毁开发者工作的途径。

2026年1月 Anthropic 推出 Claude Cowork 后不久，一家风投公司的创始人 Nick Davidov 使用 Claude Cowork（一款通用型 AI 代理产品）来整理妻子的桌面。他明确仅授权临时 Office 文件的权限。然而，代理通过终端命令绕过 macOS 垃圾箱，删除了一个包含15年家庭照片的文件夹（约15,000至27,000个文件）。Davidov 最终能恢复照片，是因为 iCloud 的30天保留策略恰好仍在生效。垃圾箱完全被绕过了。

这些并非孤立事件，而是同一故事的不同路径版本。

故障的工作原理

要理解为何这类事件不断发生，我们需要审视现代 AI 编码代理在开发者机器上执行命令的架构。代理的行为完全符合其设计初衷。真正的失败在于架构本身。

  • 编码代理（Claude Code、Cursor、Replit、Kiro） 是一个由 AI 驱动的 shell。它读取你的提示，推理如何满足该提示，生成一条命令，并直接在你的操作系统上运行该命令。不存在需要人类批准的独立“执行提案”步骤。推理步骤和执行步骤是同一个步骤。
  • 用户的 shell 是你在启动代理时继承的 shell。在 macOS 上，通常是 zsh。代理的命令通过这个 shell 执行，并拥有开发者完整的用户权限。~ 会扩展为开发者的主目录，因为在 zsh 中 ~ 就代表主目录。
  • 权限继承 是隐式且完全的。开发者 shell 能做的任何事情，代理都能做。不存在“代理代表开发者行事”的独立身份。只要会话持续，代理就是开发者本人。
  • `--dangerously-skip-permissions` 标志，Lanzani 的技术博客文章对此进行了详细分析，正是这个标志移除了默认存在的唯一安全防护。如果没有该标志，Claude Code 会在执行每个 shell 命令前请求确认；而启用该标志后，代理会在后台运行命令，开发者可以继续处理其他工作。

最后这一点至关重要。该标志之所以存在，是因为默认行为——对每个 shell 命令都要求确认——会让多步骤任务变得繁琐。开发者添加该标志是为了让代理真正有用。但这样一来，代理便能在无人干预的情况下执行破坏性命令。该标志名称诚实无欺：它确实危险。但它也很受欢迎，因为另一种选择是必须手动批准代理运行的每一个 ls 和 cat。

漏洞发生在第 2 步和第 3 步之间。 代理推理出要运行的命令，shell 在主机上执行该命令。两者之间没有任何中间层。没有架构上的边界来判断“此命令将删除用户主目录，拒绝执行”。shell 只看到一个语法正确的 rm -rf，于是就执行了 rm -rf 的功能。

技术剖析：一个尾随斜杠如何清空 Mac

以下是事件逐步展开的过程：

Image 7: image3 2

_图注：示意图说明不受限制的 AI 代理执行如何将简单的清理任务升级为整个主目录的彻底删除_

1. 用户请求

开发者请 Claude Code 清理旧仓库中的包。这个提示是每个开发者每天都会输入的类型：

请从这个旧仓库中清理未使用的测试文件、补丁和计划文档。

2. 代理的推理

代理识别出三个符合请求的目录：tests/、patches/ 和 plan/。然后它生成一条 rm -rf 命令，因为递归删除目录是标准做法。到目前为止，这属于正常行为。

3. 幻想出的参数

代理在命令末尾附加了 ~/。我们无法确切知道原因。可能是代理推断“清理”也包括整理主目录；也可能它把 ~/ 当作无操作分隔符生成，却未意识到这是一个具有破坏性的参数；还可能其训练数据中包含类似位置出现 ~/ 的 shell 片段，导致它进行了模式匹配。无论哪种情况，结果都一样：

rm -rf tests/ patches/ plan/ ~/

这是一个语法正确的 shell 命令。语法本身并不会标记“这是危险的”。

4. shell 展开

当该命令在 macOS 上的 zsh 中运行时，shell 会将 ~/ 展开为 /Users/loveswarkin/。命令实际上变为：

rm -rf tests/ patches/ plan/ /Users/loveswarkin/

shell 不会发出警告，不会请求确认，也不会标记主目录为受保护区域。系统层面没有任何检查机制说“此命令将删除用户整个主目录”。shell 只做它该做的事：展开路径并执行。

5. 递归强制删除

rm -rf 会遍历每个参数下的文件系统并删除所有内容。桌面、文档、Library、钥匙串、Application Support 文件夹、Claude Code 自身的配置和凭据、用户的 SSH 密钥、git 配置、用户的照片……全部被删除。按顺序，毫不停顿。

由于大部分文件都很小，且 SSD 控制器几乎立即确认删除操作，整个删除过程仅需数秒完成。等到用户发现终端无响应并切换标签页查看时，一切已经结束。

6. 后果

钥匙串已消失，意味着所有依赖钥匙串认证的应用程序均已登出：邮件、浏览器、Slack、GitHub Desktop、所有存储了令牌的服务、所有保存的密码。该机器上的用户身份基础设施已不复存在。

Claude Code 本身也无法再认证，因为它的凭据存储在主目录中。执行破坏操作的代理甚至无法正确道歉，因为它无法连接自己的后端服务。

影响

仅通过一次命令执行，开发者便：

  • 失去了多年积累的个人与职业文件
  • 失去了访问远程系统的加密密钥（SSH、GPG）
  • 失去了系统上所有应用程序的认证状态
  • 失去了尚未提交工作的 git 历史记录
  • 继承了一个部分损坏的系统，重新登录和重装应用将耗时数天

没有任何恢复途径。启用了 TRIM 的 SSD（现代 Mac 的默认设置）会在控制器级别清零释放的块，因此即使使用取证恢复工具也无法找回数据。数据并非“被删除”（即标记为不可用但可恢复），而是彻底消失了。

这就是一个 AI 生成命令中多余的尾随斜杠所造成的后果。

Image 8: image1 2

Docker 沙箱如何消除这一攻击向量

当前的 AI 编码代理生态系统迫使开发者陷入与 MCP 生态系统在我们系列文章第一部分中对用户造成的相同危险权衡。每次你运行 claude --dangerously-skip-permissions 或其他代理中的等效标志时，你都是直接在主机系统上执行任意由 AI 生成的命令，并拥有完全访问权限：

  • 你的整个文件系统
  • 你的主目录及其所有内容
  • 你的凭证、密钥链、SSH 密钥和云配置
  • 所有正在运行的进程以及你的 shell 可以建立的每一个网络连接

这正是 rm -rf ~/ 事件造成系统彻底毁灭的方式。代理以开发者的身份运行，在开发者的文件系统上运行，没有任何架构边界来阻止它。

Docker 的安全优先架构

Docker Sandboxes 代表了 AI 编码代理执行方式的根本性转变。代理不再直接在主机上以用户权限运行，而是运行在一个拥有独立内核、独立文件系统和独立网络的微虚拟机（microVM）中。代理所看到的 ~/ 是工作区挂载点，而不是开发者实际的主目录。从沙箱内部看，开发者的实际主目录根本不存在。

Docker Sandboxes 通过 sbx CLI 进行管理。这里有一个值得区分的关键点：Docker Sandboxes 是代理实际运行的隔离微虚拟机环境；而 `sbx` 是用于创建、启动和管理这些环境的独立 CLI 工具。Sandboxes 是环境本身，sbx 是你用来控制它们的命令。

Docker Sandboxes 通过架构设计从根本上解决了 rm -rf ~/ 类型的故障。即使代理生成并成功执行 rm -rf tests/ patches/ plan/ ~/ 命令，被删除的也只是沙箱内的工作区，而非开发者真实的主目录。由于主机文件系统在微虚拟机内部不可见，因此没有任何东西可以被删除。

仅限工作区的执行

最重要的架构转变是：代理所看到的文件系统视图仅限于工作区挂载点，且仅此而已。

bash
# 安装 sbx 并登录
brew install docker/tap/sbx
sbx login

# 在项目目录限定的工作区沙箱中启动代理
cd ~/my-project
sbx run claude

三条命令后，代理便已在微虚拟机中运行。在沙箱内部，代理所看到的 ~/ 就是工作区，而不是开发者真实的主目录。Library 文件夹、密钥链、SSH 密钥、AWS 配置——这些在沙箱内部统统不存在。代理无法触及它看不到的东西。

在沙箱内部执行 rm -rf ~/ 只会删除工作区文件。开发者可以用 sbx rm 直接丢弃沙箱并重新开始。主机系统毫发无损。

默认阻止凭证路径挂载

即使开发者显式地将额外路径挂载进沙箱，默认情况下也会阻止常见凭证目录的挂载：

bash
# 默认阻止挂载的凭证根目录：
#   ~/.aws  ~/.ssh  ~/.docker  ~/.gnupg
#   ~/.netrc  ~/.npm  ~/.cargo  ~/.config
# 尝试包含这些路径的错误挂载配置会在沙箱启动前被拒绝。
sbx run claude

这一阻止列表直接应对了 LovesWorkin 事件中密钥链被删除的问题。即使代理决定递归删除其工作区，也无法触及保持开发者认证状态完整的凭证。

敏感工作区的只读挂载

对于代理只需读取而不应写入目录的工作流，使用 :ro 后缀可声明挂载为只读：

bash
# 将项目工作区挂载为可写，文档目录挂载为只读
sbx run --name docs-review claude /path/to/project /path/to/docs:ro

对只读挂载执行 rm -rf 会在内核级别失败。微虚拟机会强制执行挂载模式，这意味着代理无法通过推理、提示操控或滥用标志来覆盖该限制。基础设施决定了什么可写，模型没有投票权。

风险操作的 Git 工作树隔离

对于清理任务、重构或“让我简单清理一下”这类具有破坏性的操作，sbx run --branch 允许代理在隔离的 Git 工作树上操作：

bash
# 在全新的特性分支上创建沙箱
sbx run --name cleanup-agent --branch=cleanup /old-files claude .

# 在合并前审查清理内容
sbx exec cleanup-agent git diff main

# 如果代理做了破坏性操作，直接丢弃它
sbx rm cleanup-agent

这是对“代理决定删除并重建数据库架构”问题的架构级解决方案。代理所做的更改永远不会影响主分支，直到开发者进行审查。如果代理执行 rm -rf ~/，只会清除工作树，而主分支保持不变。开发者通过 git diff main 查看变更，再决定是否合并或丢弃。

设计即“一次性”的沙箱

最后一点是，沙箱天生就是为被丢弃而设计的：

bash
# 工作完成后，列出活跃沙箱并移除已完成的那个：
sbx ls
sbx rm <sandbox-name>

这正是 Docker Sandboxes 模型与在主机上运行代理的根本区别。在主机上，破坏性命令会造成永久性损害；而在沙箱中，每个会话都是临时的。代理最坏的情况只是摧毁工作区，而工作区可以从源代码仓库轻松重现。密钥链、凭证、多年积累的个人数据——这些都无法被触及，因为在沙箱内部它们根本不存在。

实际应用中的效果

以下是 LovesWorkin 事件在 Docker Sandboxes 下的重演。用户提出同样的问题，代理生成相同的命令，shell 执行相同的展开。

在 Docker 沙箱之后：

bash
$ cd ~/my-project
$ sbx run claude
> 请清理未使用的 test 文件、补丁和计划文档
[Agent 执行: rm -rf tests/ patches/ plan/ ~/]
[沙箱内的工作区已被清除。主机 home 目录保持完整。]

沙箱是临时的。列出并删除它以重新开始：

bash
$ sbx ls
$ sbx rm <sandbox-name>

代理的行为完全相同，但架构结果完全不同。

实际改进

| 安全方面 | 传统 AI 编码代理 | Docker 沙箱 | |----------|------------------|-------------| | 执行环境 | 直接在用户主机上执行 | 隔离的微虚拟机（microVM），拥有独立内核 | | 文件系统视图 | 完整主机文件系统，包括 ~/ | 仅挂载工作区 | | 凭据访问 | 用户 home 目录中的所有凭据 | 默认阻止凭据路径访问 | | 破坏性命令影响 | 对主机造成永久性损害 | 临时沙箱，无持久影响 | | 合并前审查 | 无 | 使用 Git worktree 隔离，通过 sbx exec <sandbox-name> git diff main 进行审查 | | 恢复能力 | 通常不可能（TRIM 清零块） | 使用 sbx rm 删除后可重新开始 |

安全部署 AI 编码代理的最佳实践

  1. 停止直接在主机上运行编码代理。 容器化或微虚拟机隔离应作为默认选项，而非高级功能。
  2. 对涉及文件系统操作的每个编码任务使用 `sbx run`。 尤其是“清理”、“整理”、“重构”和“删除未使用项”等提示词。这些是最可能生成破坏性 rm -rf 命令的类别。
  3. 对破坏性操作使用 Git worktrees。 sbx run --name <name> --branch=<branch> claude 可确保代理的更改在触及主分支前可被审查。
  4. 切勿在主机上使用 `--dangerously-skip-permissions`。 如果需要代理无需逐条命令批准即可运行，请将其置于沙箱中。沙箱边界正是让“跳过权限”变得安全的原因。
  5. 将沙箱视为一次性使用。 不要在其中存储任何重要数据。其核心价值在于你可以随时 sbx rm 并重新开始。
  6. 审计策略日志。 sbx policy log 显示每次允许或拒绝的连接尝试，若出现问题，这将成为你的取证追踪记录。

立即行动：今天就为你的 AI 编码代理增强安全

安全执行 AI 编码代理的第一步，从一条命令开始。以下是脱离在主机上运行代理的方法：

  • 安装 Docker 沙箱。 访问Docker 沙箱文档，在五分钟内安装 sbx 并运行你的第一个沙箱代理。
  • 将其融入现有工作流。 sb8 run claude（或 sbx run cursor、sbx run codex 等）可将你现有的代理无缝放入微虚拟机中，无需任何配置更改。
  • 阅读架构深度解析。 Docker 沙箱架构文档 解释了微虚拟机模型、工作区挂载机制以及网络策略层。
  • 浏览 MCP 目录。 如果你的代理使用 MCP 服务器，Docker MCP 目录 提供容器化、经过验证的服务器，与沙箱代理执行相辅相成。

结论

LovesWorkin 事件、Mike Wolak 的 Ubuntu 系统清空、Claude Cowork 删除家庭照片、GitHub Issue #12637 的 shell-glob 展开漏洞——这些都是同一个故事。AI 编码代理在执行任务时推理出一个包含破坏性参数的命令，而由于架构中没有任何机制阻止该命令，shell 最终执行了它，从而摧毁了开发者的成果。

这不是 Claude Code、Cursor、Kiro 或任何特定代理的 bug。这是执行模型本身的属性。只要代理以用户权限在主机上运行，这类失败就会持续发生，每次都会出现新的变种。

Docker 沙箱并不试图让代理变得更聪明，而是改变了代理的运行位置。代理获得了一个工作区，但它没有获得你的机器。

_系列下一篇预告：第 3 期将探讨 AWS Cost Explorer 服务中断事件，当时亚马逊自己的 Kiro 代理在几秒钟内决定删除并重建生产环境，以及如何通过受限身份沙箱配置防止此类故障。_

了解更多

关于作者

Image 9: Ajeet Raina 的头像照片

Ajeet Singh Raina

Docker 开发者倡导者

Ajeet Singh Raina 是 Docker 的开发者倡导者，专注于容器、Docker Compose 与 AI 领域，致力于帮助开发者自信构建应用。

AI AgentDocker SandboxesProducts

目录

[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.docker.com%2Fblog%2Fcoding-agent-horror-stories-the-rm-rf-incident%2F "访问此 LinkedIn 个人主页")[](https://twitter.com/intent/tweet?url=https%3A%2F%2Fwww.docker.com%2Fblog%2Fcoding-agent-horror-stories-the-rm-rf-incident%2F "访问此 X 个人主页")[](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fwww.docker.com%2Fblog%2Fcoding-agent-horror-stories-the-rm-rf-incident%2F "访问此 Facebook 个人主页")

相关文章

产品

功能

开发者

定价

公司

语言

  • [](http://twitter.com/docker)
  • [](https://www.linkedin.com/company/docker)
  • [](https://www.instagram.com/dockerinc/)
  • [](http://www.youtube.com/user/dockerrun)
  • [](https://www.facebook.com/docker.run)
  • [](https://www.docker.com/blog/feed)

© 2026 Docker Inc. 保留所有权利

服务条款隐私政策法律声明

Cookie 设置

通过点击“接受所有 Cookie”，您同意在您的设备上存储 Cookie，以增强网站导航、分析网站使用情况，并协助我们的营销工作。

Cookie 设置 拒绝全部 接受所有 Cookie

Image 13: 公司标志

隐私偏好中心

当您访问任何网站时，该网站可能会在您的浏览器中存储或检索信息，通常以 Cookie 的形式存在。这些信息可能与您、您的偏好或您的设备有关，主要用于使网站按预期方式运行。这些信息通常不会直接识别您的身份，但可以为您提供更个性化的网络体验。由于我们尊重您的隐私权，您可以选择不允许某些类型的 Cookie。请点击不同类别的标题以了解更多信息并更改默认设置。然而，阻止某些类型的 Cookie 可能会影响您对网站的体验以及我们能够提供的服务。

更多信息

允许全部

管理同意偏好

#### 功能性 Cookie

  • [x] 功能性 Cookie

这些 Cookie 使网站能够提供增强的功能和个性化服务。它们可能由我们或我们添加到页面中的第三方服务提供商设置。如果您不允许这些 Cookie，则部分或全部服务可能无法正常运行。

#### 严格必要的 Cookie

始终激活

这些 Cookie 是网站正常运行所必需的，无法在我们的系统中关闭。它们通常仅在您执行相当于请求服务的操作（如设置隐私偏好、登录或填写表单）时设置。您可以设置浏览器以阻止或提醒您这些 Cookie，但网站的部分功能将无法正常使用。这些 Cookie 不会存储任何可识别个人身份的信息。

#### 性能 Cookie

  • [x] 性能 Cookie

这些 Cookie 允许我们统计访问量和流量来源，以便衡量和改进网站性能。它们帮助我们了解哪些页面最受欢迎或最不受欢迎，并观察访客在网站上的浏览路径。这些 Cookie 收集的所有信息都是汇总且匿名的。如果您不允许这些 Cookie，我们将无法知道您何时访问了我们的网站，也无法监控其性能。

#### 定向 Cookie

  • [x] 定向 Cookie

这些 Cookie 可能通过我们的广告合作伙伴在我们的网站上设置。这些公司可能会利用它们建立您的兴趣档案，并在其他网站上向您展示相关广告。它们不直接存储个人信息，而是基于唯一标识您的浏览器和互联网设备。如果您不允许这些 Cookie，您将看到较少的定向广告。

Cookie 列表

清除

  • [x] 复选框标签 标签

应用 取消

同意 法律利益

  • [x] 复选框标签 标签
  • [x] 复选框标签 标签
  • [x] 复选框标签 标签

拒绝全部 确认我的选择

Image 14: 由 OneTrust 提供支持

Image 15Image 16

AI 可能会生成不准确的信息，请核实重要内容