コーディングエージェントのホラーストーリーズ:The rm -rf ~/ インシデント

これは『AI Coding Agent Horror Stories』シリーズの第 2 部であり、実際のセキュリティインシデントがAIコーディングエージェントの脆弱性を露呈する詳細な検証と、Docker Sandboxが実行層での最悪の失敗を含むワークスペーススコープによる隔離をどのように実現するかを詳しく解説します。

このシリーズのパート1では、AIコーディングエージェントの失敗の6つのカテゴリーと、それが繰り返されるアーキテクチャ的な理由をマッピングしました。エージェントはあなたのファイルシステム上で、あなたの認証情報で実行され、モデルの決定とシェルの実行の間に何も存在しないということです。パート 2では、エコシステム全体で最も破壊的な失敗モード、すなわちAIコーディングエージェントが開発者のホームディレクトリを一つのコマンドで削除するという点について深く掘り下げます。

今日のホラーストーリー:マックを拭いたティルデ

2025年12月、u/LovesWorkinというハンドルネームでRedditのユーザーが、その年最も議論されたAIコーディングエージェントのインシデントの一つを共有しました。彼らはクロード・コードに古いリポジトリの整理を依頼した。クロードは rm -rf tests/ patches/ plan/ ~/を実行し、その ~/ が彼らのMac全体を消去しました。

これはCVEではありませんでした。それは高度な攻撃ではなかった。AIのコーディングエージェントが、ユーザーが予想しなかった方法で指示通りに行動し、ミスを捉えるためのアーキテクチャ的な境界もなかったのです。

今号では、次のことを学びます。

• rm -rfコマンドの一つだけの後ろ切り線が開発者のMac全体を消し去った方法
• なぜ --dangerously-skip-permissions フラグが存在するのか、そして開発者がそれを使い続ける理由
• このインシデントは、GitHub-issue-#10077 UbuntuのワイプやClaude Coworkのファミリーフォト事件と共通しています
• Docker Sandboxが実行層でこの失敗のクラス全体を含んでいること

このシリーズが重要な理由

このシリーズの各「ホラーストーリー」は、実験室の発見が生産の失敗に発展する現実世界の事件を検証します。これらは仮定の攻撃ではありません。被害者の名前が明かされた記録された事例、スクリーンショットされたコマンドログ、そしていくつかのケースではベンダーからの公的な謝罪も含まれています。私たちの目標は、セキュリティ統計の背後にある人間的影響を示し、これらの失敗が実際にどのように展開するかを示し、Dockerのワークスペーススコープ実行モデルを通じてAI開発インフラを保護する具体的な指針を提供することです。

物語は、すべての開発者がやっていることから始まります。エージェントに古いリポジトリのクリーンアップを依頼することです。

問題を

12月8日、2025、u/LovesWorkinというハンドルネームで開発者がr/ClaudeAIにRedditのスレッドを投稿しました。タイトルは「Claude CLIが私のホームディレクトリ全体を削除しました!マックを全部拭き取った。」この投稿は数時間で1を突破し、500アップボートを獲得し、Xのサイモン・ウィリソンによって拡幅され、12月16日には日本のギガジンで取り上げられ、2025のAIコーディングエージェントに関する最も議論された事件の一つとなりました。

セットアップは特に目立ったものではありませんでした。ユーザーは古いリポジトリのパッケージのクリーンアップをClaude Codeに依頼しました。定期的なメンテナンス、開発者なら何も考えずに任せるようなものだ。Claudeが生成し実行した:

rm -rf tests/ patches/ plan/ ~/

表面的には、これは3つのプロジェクトディレクトリを削除するコマンドです。致命的な誤りはトレーリング ~/です。Unixでは、 ~ ユーザーのホームディレクトリに拡張されます。~/ 下部のスラッシュは「ホームディレクトリ内のすべて」を意味します。rm -rfと組み合わせると、再帰的かつ確認なしに削除されるため、このコマンドはユーザーのホームディレクトリ全体を一気に削除します。

数秒のうちに、開発者は敗北しました:

• デスクトップ、ドキュメント、ダウンロードの各フォルダ
• システム上のすべてのアプリの状態を含むライブラリフォルダ
• このキーチェーンは、すべてのアプリで認証を破り、Claude Code自体もも自社のバックエンドと通信できなくなりました
• 何年分のプロジェクトファイル、家族写真、仕事成果物
• すべてSSDに保管されており、TRIMはリカバリーを試みるまでにすでに解放ブロックをゼロ化していました

回復は見られませんでした。開発者が元のスレッドで言っていたように:「Mac全体を壊した!なんだこれ?」

キャプション:AIエージェントが直接ファイルシステムにアクセスすると、「私のデスクトップを整理する」というのは壊滅的な問題になり得ます。

問題の規模

これは一度きりの事件ではありませんでした。それはパターンの一例だった。

LovesWorkin事件の数週間前、2025年10月21日、開発者のMike WolakはClaude Codeリポジトリに対してGitHub Issue #10077を提出しました。Wolakの報告書では、Ubuntu/WSL2でも同様の失敗が報告されていました。Claude Codeはrootから rm -rf を実行し、ログには /bin、 /boot、 /etc に対して数千件の「許可拒否」メッセージが表示され、エージェントが所有していないファイルを削除しようとシステム内で進んでいました。システム上のユーザー所有ファイルはすべて消えていました。Anthropicはこの問題にタグ付けarea:securityとbug。ウォラックの報告書の決定的な詳細は、彼が共に行動していたわけではない--dangerously-skip-permissionsということです。Claude Codeの許可システムは、ユーザーが承認する前にエージェントのコマンドが破壊的に拡大することを検知できなかっただけだ。

2週間後の11月 28日、 2025年、 GitHubのissue #12637 はまた別のバリアントを記録しました。Claude Codeは以前、誤って文字通り ~ と名付けられたディレクトリを作成していました。その後、エージェントが引用符なしの rm -rf ~を実行してそのディレクトリをクリーンアップしようとした際、シェルはrmがその引数に気づく前にユーザーの実際のホームディレクトリに ~ 展開してしまいました。同じ破壊的な結果ですが、まったく異なるメカニズムです。エージェントは開発者の作品を破壊する新たな方法を見つけた。

1月 2026 日にAnthropicのClaude Coworkがローンチされた直後、ベンチャーキャピタルの創業者ニック・ダビドフは、妻のデスクトップを整理するためにAnthropicの汎用AIエージェント製品であるClaude Coworkを使いました。彼は一時的なオフィスファイルのみを明確に許可しました。エージェントは、15、000、27000ファイルの間の15年分の家族写真を含むフォルダを、macOSのトラッシュを完全に回避するターミナルコマンドで削除しました。ダビドフが写真を回収したのは、iCloudの 30日保存がまだ有効だったからです。ゴミは完全に回避されていた。

これらは孤立した話ではありません。同じ話ですが、ファイルパスが違うだけです。

失敗の仕組み

なぜこれらのインシデントが頻繁に起こるのかを理解するには、現代のAIコーディングエージェントが開発者のマシン上でコマンドをどのように実行しているかのアーキテクチャを見る必要があります。エージェントは設計通りに動作しています。アーキテクチャが失敗です。

• コーディングエージェント(Claude Code、Cursor、Replit、Kiro) はAI駆動のシェルです。プロンプトを読み取り、それを満たす方法を考え、コマンドを生成し、そのコマンドを直接あなたのOS上で実行します。人間が承認する「実行提案」の別個のステップはありません。推論ステップと実行ステップは同じステップです。
• ユーザーズシェルとは 、エージェントが起動時に受け継いだシェルのことです。macOSでは通常はzshです。エージェントのコマンドは開発者の完全なユーザー権限でこのシェルを通過します。~ 開発者のホームディレクトリに拡張します。なぜなら、ZSHで ~ がそういう意味だからです。
• 許可継承 は暗黙的かつ完全です。開発者のシェルができることは、エージェントにもできる。「開発者の代理として行動するエージェント」には別の識別名はありません。エージェントはセッションが続く限り開発者です。
• --dangerously-skip-permissionsランザーニの技術ブログ記事で詳細に分析されている旗は、デフォルトで存在する唯一の安全網を取り除くものだ。旗がなければ、クロードコードは各シェルコマンドの前に確認を求めます。この方法では、開発者が他の作業に戻る間、エージェントはバックグラウンドでコマンドを実行します。

この最後の点こそが重要なポイントです。このフラグが存在するのは、デフォルトの動作であるすべてのシェルコマンドで確認を求めるため、多段階の作業が煩雑に感じられるからです。開発者はエージェントを有用にするためにフラグを追加します。エージェントは介入なしに破壊的な命令を実行する能力を持つようになります。旗の名前は正直に言えます。それは危険な旗です。しかし、それはまた人気のある選択肢でもあります。なぜなら、代替案としてはエージェントが実行するすべての ls と cat を承認することだからです。

脆弱性はステップ 2 と 3の間に発生します。エージェントはどのコマンドを実行するかを考えます。シェルはそのコマンドをホストに実行します。その間には何もありません。「このコマンドはユーザーのホームディレクトリを削除し、実行を拒否する」というアーキテクチャ上の境界はありません。シェルは文法的に有効な rm -rf を認識し、 rm -rf の行動を取る。

技術的な解説:後続のスラッシュがMacを消し去る方法

事件の経緯を段階的に説明します:

キャプション:制限のないAIエージェント実行が単純なクリーンアップ作業を完全なホームディレクトリ破壊にエスカレートさせる方法を示す図

1。ユーザーのリクエスト

開発者は古いリポジトリのパッケージをクリーンアップするようClaude Codeに依頼します。このプロンプトは、すべての開発者が毎日タイプするようなものです:

Please clean up unused test files, patches, and plan documents from this old repo.

2。エージェントの理由

エージェントはリクエストに合致する3つのディレクトリ( tests/、 patches/、 plan/)を特定します。その後、ディレクトリを削除するのが標準的な削除方法であるため、 rm -rf コマンドを生成します。今のところ、これは正しい行動です。

3。幻覚の議論

エージェントはコマンドに ~/ を追加します。なぜそうなったのかは正確にはわかっていません。おそらくそのエージェントは「片付け」には自宅の名簿の整理も含まれていると推測したのでしょう。おそらくノーオペレーターの分離 ~/ を生み出し、それが破壊的な議論だと気づかなかったのかもしれません。おそらく訓練データには、 ~/ がこの位置に現れパターンマッチしたシェルの断片が含まれていた可能性があります。結果はどちらにせよ同じです:

rm -rf tests/ patches/ plan/ ~/

これは構文的に有効なシェルコマンドです。構文には「これは危険だ」とは言われていません。

4。シェル膨張

このコマンドがmacOSのzshで実行されると、シェルは~//Users/loveswarkin/に展開します。このコマンドは実質的に次のようになります:

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

砲弾は警告を発しません。それは確認していません。ホームディレクトリは保護されていると表示されません。「このコマンドでユーザーのホームディレクトリ全体を削除する」というシステムレベルのチェックはありません。シェルはシェルらしくパスを展開し実行します。

5。再帰的力の削除

rm -rf 各引数の下にファイルシステムを歩き、すべてを削除します。デスクトップ、ドキュメント、ライブラリ、キーチェーン、アプリケーションサポートフォルダ、Claude Code独自の設定と認証情報、ユーザーのSSHキー、ユーザーのgit設定、ユーザーの写真などです。全部だ。順番通りに。ためらうことなく。

削除は数秒で完了します。なぜなら、これらのファイルはほとんどが小さく、SSDのコントローラーがほぼ即座に削除を認識するためです。ユーザーが端末が反応しないことに気づき、チェックするためにタブを外す頃には、すでに完了しています。

6。その後

キーチェーンがなくなり、そのキーチェーンに対して認証されたすべてのアプリがログアウトされた状態になります。メール、ブラウザ、Slack、GitHub Desktop、トークンを保存するすべてのサービス、保存されたすべてのパスワード。そのマシン上のユーザーのアイデンティティインフラは消えています。

Claude Code自体は認証ができず、自身の認証情報がホームディレクトリに存在していたためです。破壊したエージェントは、自分のバックエンドに接続できないため、きちんと謝ることすらできません。

影響

単一のコマンド実行内で、開発者は以下のことを成し遂げます:

• 失われた個人的・職業的ファイルの長年を
• リモートシステムにアクセスするために必要な失われた暗号鍵(SSH、GPG)
• システム上のすべてのアプリの認証状態を失いました
• コミットしていない作業のgit履歴を失いました
• 部分的に壊れたシステムを引き継ぎ、再ログインやアプリの再インストールに数日かかる

回復の道筋はありません。TRIMを有効にしたSSDは、コントローラーレベルで解放されたブロックがゼロなので、法医学の復旧ツールも何も見つかりません。データは「利用不可とマークされているが回復可能」という意味での「削除」ではありません。もういない。

これがAI生成コマンドの一撃で繰り返される結果です。

Dockerサンドボックスがこの攻撃ベクトルを排除する方法

現在のAIコーディングエージェントエコシステムは、MCPエコシステムが私たちのシリーズのパート1でユーザーに強いられたのと同じ危険なトレードオフに開発者を追い込んでいます。他のエージェントで claude --dangerously-skip-permissions または同等のフラグを実行するたびに、ホストシステム上で任意のAI生成コマンドを直接実行し、以下に完全アクセス権を持っています:

• ファイルシステム全体
• あなたのホームディレクトリとその中のすべて
• 認証情報、キーチェーン、SSHキー、クラウド設定
• 実行中のすべてのプロセスとシェルのネットワーク接続が可能

まさにこれが rm -rf ~/ インシデントがシステムの完全な破壊をもたらす方法だ。エージェントは開発者として、開発者のファイルシステム上で動作し、それを止めるアーキテクチャ上の境界はありません。

Docker のセキュリティ第一のアーキテクチャ

Docker Sandboxes は、AIコーディングエージェントの実行方法における根本的な転換を示しています。ホスト上でユーザーレベルの権限で直接動作するのではなく、エージェントは独自のカーネル、ファイルシステム、ネットワークを持つmicroVM内で動作します。エージェントの表示 ~/ はワークスペースマウントであり、開発者の実際のホームディレクトリではありません。開発者の実際のホームディレクトリはサンドボックス内からは存在しません。

Docker Sandboxは sbx CLIを通じて管理されます。ここで簡単に区別しておくべき点は、 Dockerサンドボックス とは、エージェントが実際に動作する孤立したmicroVM環境のことです。sbx は、それらの作成、起動、管理に使用されるスタンドアロンCLIツールです。サンドボックスは環境のことです。sbx コントロールするために入力するものです。

Docker Sandboxは、破壊的なコマンドをアーキテクチャ的に不可能にすることで、 rm -rf ~/ の障害クラスを解決します。エージェントは間違いなく rm -rf tests/ patches/ plan/ ~/を生み出すことができます。そのコマンドは絶対に実行できます。指揮は絶対に成功する。しかし削除されるのは、開発者の実際のホームディレクトリではなく、サンドボックス内のワークスペースです。ホストファイルシステムはmicroVMの内部からは見えないので、削除するものはありません。

ワークスペース・スコープ実行

最も重要なアーキテクチャの変化は、エージェントのファイルシステムビューがワークスペースマウントのみであるということです。

# Install sbx and sign in
brew install docker/tap/sbx
sbx login

# Launch the agent inside a sandbox scoped to the project directory
cd ~/my-project
sbx run claude

3つのコマンドでエージェントはmicroVM内で動作します。サンドボックス内から見ると、エージェントの ~/ は開発者の実際のホームディレクトリではなく、ワークスペースそのものです。Libraryフォルダ、キーチェーン、SSHキー、AWS設定など、サンドボックス内には存在しません。エージェントは見えないものに届くことはできません。

サンドボックス内の rm -rf ~/ はワークスペースファイルを削除します。開発者は sbx rm と共にサンドボックスを捨てて、新たにやり直すことができます。ホストシステムは手つかずのままです。

ブロックされた認証経路

開発者がサンドボックスに追加パスを明示的にマウントしても、共通の認証ディレクトリはデフォルトでマウントできません。

# Credential roots blocked by default:
#   ~/.aws  ~/.ssh  ~/.docker  ~/.gnupg
#   ~/.netrc  ~/.npm  ~/.cargo  ~/.config

# A misconfigured mount that tries to include these is rejected
# before the sandbox even starts.
sbx run claude

このブロックリストは、LovesWorkin事件によるキーチェーン削除の影響に直接対応しています。エージェントが再帰的にワークスペースを削除しても、開発者の認証状態を保つ認証情報にアクセスできません。

機密作業スペース向けの読み取り専用マウント

エージェントがディレクトリを読み込むが書き込みしないワークフローでは、:roのサフィックスでマウントを読み取り専用として宣言します:

# Mount the project workspace as writable, the docs as read-only
sbx run --name docs-review claude /path/to/project /path/to/docs:ro

読み取り専用マウントに対する rm -rf はカーネルレベルで失敗します。microVMはマウントモードを強制するため、エージェントは推論やプロンプト操作、フラグの誤用によってマウントモードを上書きすることはできません。何が書き取れるかはインフラが決める。モデルには投票権がありません。

リスクの高い操作のためのgit-worktree隔離

クリーンアップタスクやリファクタリング、「これをクリーンアップするだけ」といった破壊的な操作については、 sbx run --branch エージェントが孤立したGitワークツリー上で動作できるようにします。

# Create a sandbox on a fresh feature branch
sbx run --name cleanup-agent --branch=cleanup/old-files claude .

# Review what got cleaned up before merging
sbx exec cleanup-agent git diff main

# If the agent did something destructive, throw it away
sbx rm cleanup-agent

これは「エージェントがスキーマを放棄して再作成することを決めた」というアーキテクチャ的な答えです。エージェントの変更は開発者がレビューするまでメインブランチには影響しません。エージェントが rm -rf ~/実行すると、ワークツリーは消去され、メインブランチはそのまま残ります。開発者はこの git diff mainを見直し、何が起きたかを確認し、統合するか破棄するかを決めます。

使い捨てサンドボックス by Design(デザインによるもの)

最後に、サンドボックスは捨てられるように設計されています。

# When the work is done, list active sandboxes and remove the one you're done with:
sbx ls
sbx rm <sandbox-name>

これがDockerサンドボックスモデルがホスト上でエージェントを実行することと根本的に異なる点です。ホストでは、破壊命令が永久的なダメージを残します。サンドボックスの中では、すべてのセッションが使い捨てです。エージェントができる最悪のことはワークスペースを破壊することだけで、これはソースリポジトリから再現可能です。キーチェーン、認証情報、長年の個人データ、それらは一切触れられません。なぜなら、それらは砂場の中からは存在しないからです。

実際の様子

こちらはLovesWorkinの出来事をDockerサンドボックスで再生したものです。そのユーザーも同じ質問をしています。エージェントも同じコマンドを生成します。シェルも同じ展開を実行します。

# After Docker Sandboxes:
$ cd ~/my-project
$ sbx run claude
> Please clean up unused test files, patches, and plan documents
[Agent runs: rm -rf tests/ patches/ plan/ ~/]
[Workspace inside the sandbox wiped. Host home directory intact.]

# The sandbox is throwaway. List it and remove it to start fresh:
$ sbx ls
$ sbx rm <sandbox-name>

エージェントの行動は同じです。アーキテクチャ的な結果はまったく異なります。

実践的な改善

安全なAIコーディングエージェント展開のベストプラクティス

1. ホスト上で直接コーディングエージェントを実行するのはやめましょう。コンテナ化やmicroVMの分離はデフォルトにすべきで、高度なオプションではありません。
2. ファイルシステム操作を含むすべてのコーディングタスクに sbx run を使用してください。特に「クリーンアップ」「整理」「リファクタリング」「未使用の削除」プロンプトが特にそうです。これらは破壊的な rm -rfを生み出す可能性が最も高いプロンプトカテゴリーです。
3. 破壊操作にはGitワークツリーを使いましょう。 sbx run --name <name> --branch=<branch> claude エージェントの変更がメイン支店に届く前に確認可能であることを確認しましょう。
4. ホストマシンで --dangerously-skip-permissions を使わないでください。コマンドごとの承認なしにエージェントがコマンドを実行する必要がある場合は、サンドボックス内で実行してください。サンドボックスの境界が「権限をスキップする」ことを安全にしています。
5. サンドボックスは使い捨てとして扱いましょう。重要なものは中に入れないでください。大事なのは、 sbx rm して新たに始められることです。
6. ポリシーログを監査してください。 sbx policy log 許可された接続試行や拒否されたすべての試みが表示され、もし何か問題が起きた場合のフォレンジックトライアルになります。

行動を起こしましょう:今すぐAIコーディングエージェントを安全にしましょう

安全なAIコーディングエージェント実行への道は、一つのコマンドから始まります。ホストでエージェントを動かさない方法を紹介します:

• Docker Sandboxをインストールしてください。Docker Sandboxのドキュメント にアクセスしてsbxをインストールし、最初のサンドボックスエージェントを5分以内に実行してください。
• 既存のワークフローで試してみてください。 sbx run claude (or sbx run cursor, sbx run codex, etc.) drops your existing agent into a microVM with no configuration changes required.
• アーキテクチャを深く読んでみてください。 Docker Sandboxアーキテクチャのドキュメントでは、microVMモデル、ワークスペースのマウント、ネットワークポリシー層について説明しています。
• MCPカタログをご覧ください。エージェントがMCPサーバーを使用している場合、 Docker MCPカタログ はコンテナ化され検証済みのサーバーを提供し、サンドボックス化されたエージェント実行を補完します。

結論

LovesWorkin事件、Mike WolakのUbuntuワイプ、Claude Coworkの家族写真削除、GitHubの問題#12637 shell-glob拡張バグはすべて同じ話です。AIのコーディングエージェントが、タスクを論理的に処理し、破壊的な引数を含むコマンドを生成し、シェルはそれを実行しました。なぜなら、アーキテクチャ上「このコマンドは開発者の仕事を破壊する」と言うものがなかったからです。

これらはClaude CodeやCursor、Kiro、あるいは個々のエージェントのバグではありません。それらは実行モデルの特性です。エージェントがユーザーの許可を得てホスト上で動作している限り、この障害のカテゴリーは毎回新しいバリエーションで起こり続けます。

Docker Sandboxはエージェントをより賢くしようとはしていません。エージェントがどこに逃げるかが変わります。エージェントはワークスペースを得ます。あなたのマシンを手に入れることはできません。

シリーズの次回:第 3 号では、AWSコストエクスプローラーの障害、つまりAmazonのKiroエージェントが本番環境を数秒で削除・再構築した事件、そしてそのような障害を防ぐスコープ付きアイデンティティサンドボックス構成について探ります。

詳細情報

• Docker Sandboxでエージェントを安全に実行:Docker Sandboxのドキュメントを訪れて、ワークスペース隔離エージェントの実行を数分で始めましょう。
• Docker MCPカタログの探索:Dockerのセキュリティ第一アーキテクチャを通じて、エージェントを外部サービスに接続するMCPサーバーを発見しましょう。
• Docker Desktopをダウンロード:Docker Sandbox、MCP Gateway、Model Runnerを1つのインストールで利用できる、ガバナンド制御されたAIエージェント環境への最速の道です。
• MCPホラーストーリーズシリーズをお読みください:まずは問題1から始め、ここで扱うエージェント層のリスクを補完するプロトコル層のセキュリティリスクを理解しましょう。