LLMコーディングエージェントに対する「bash権限の一括許可」が、どれほど致命的なリスクを生むか――その教訓となる投稿がr/LocalLLaMAに上がった。Claudeが連鎖bashコマンドのエスケープを誤って大量の不正ディレクトリを生成し、「修正」と称して rm -rf を含む長大コマンドを提案。投稿者は見落として実行を承認してしまったという報告だ。本記事ではこの事故の経緯と、AIエージェントを使う開発者が読み取れる防衛策を整理する。
何が起きたのか
投稿者は、Claudeが連鎖されたbashコマンドのエスケープ処理を誤った結果、不正なディレクトリ構造が大量に生成される事態に陥ったと述べている。Claudeはそれを「修正」しようとして rm -rf を含む長いbashコマンドを提案。投稿者は内容を精査せずに承認してしまい、ファイルが消失した。
How? It kept getting chained bash commands wrong, with wrong escapes. So it created many bad directories, and tried “fixing” its mistake. It offered to run a large bash command, with
rm -rfinside, and stupid me missed it.
救いとなったのは、投稿者が普段からGitHubに頻繁にpushしていた点だ。本人は「I’m glad I push everything often」と書く一方で、「the disruption is massive」（混乱は甚大だ）と続けている。なお作業環境について、投稿者はFAQで「パーソナルマシンでは実行していない。LLMコーディング専用の隔離されたProxmox VMだ」と明言している。
なぜ起きたか／何が問題か
事故の起点は、AIエージェントが生成するチェイン化されたbashコマンドのエスケープミスだ。複数コマンドが連結され、引数のクオート処理が崩れた結果、意図しないパスが大量生成された。この種のミスは珍しくないが、本件で致命的だったのは、エージェントが「自分の失敗を修正する」名目で rm -rf を含む長大コマンドを提示し、人間側のレビュー負荷の中で見落とされた点である。
元記事のコメント欄では、似たリスクへの懸念も共有されている。職場でCopilot CLIを使いながら同一マシンからk8s本番環境にアクセスできてしまっている運用への警鐘や、サンドボックス分離の不徹底を指摘する声が見られた。LLMが誤りを指摘されたときの定番応答「You’re absolutely right」を皮肉るコメントも目立つ。なお、エスケープ崩れの正確な再現条件やClaudeのバージョン等は元投稿には明示されていない。
読者がどう守るか
本投稿および関連コメントから読み取れる対策は次のとおりだ。
- 隔離環境でのみ実行する：投稿者自身もパーソナルマシンではなく専用VMで運用していた。本番環境や無関係なリポジトリへアクセスできる端末でAIエージェントを動かすのは危険。
- 頻繁にpushしてリモートに退避：本件で投稿者が救われた最大の要因は「push everything often」していたこと。
- 長大コマンドの一括承認を避ける：「修正のため」と称して提示される多段bashコマンドにこそ破壊的操作が紛れる可能性がある。
- 本番権限とエージェント実行環境を分離：コメントで指摘されたk8s prodアクセス併存問題は、企業環境でも普遍的なリスク。
なお元投稿は、具体的な再発防止のためのフラグや設定値には踏み込んでおらず、対策の解像度はあくまで運用論レベルにとどまる点には留意したい。
まとめ
- AIエージェントの「修正コマンド」にこそ破壊的処理が紛れ込みやすい
- 隔離VM・頻繁なpush・本番アクセス分離が現状の主防衛線
- 一度のbash許可は恒久的なリスクとして扱うべき
実装家視点で言うと、AIエージェントに渡すシェル権限は「毎回承認」を基本にしておくのが無難だ。一括許可は楽だが、人間の注意力は長文コマンドの末尾まで持たない。今回の事故は「VM隔離＋GitHub push」という冗長性が効いた好例で、自分の作業環境にも同レベルの保険があるか、いま一度見直しておきたい。
コメント