私はデフォルトの対話モードしか使わず、毎回手動で確認をクリックしています。この脆弱性を心配する必要がありますか？
リスクは相対的に低い。この脆弱性を悪用するには、次の2つの条件のいずれかが必要だ：--permission-mode bypassPermissionsフラグを使用する、または自分でshellの実行を許可するルールを設定する。どちらも行っておらず、単にデフォルトモードを使い毎回手動で承認しているなら、日常的な使用状況では、このalways-ask保護は原則として正常に表示されるはずだ。
ただし、リスクが低くても、バージョンを確認するために1分かける価値はある。将来あなたやチームの誰かが自動化効率を上げるために権限設定を緩めた際、バージョンが脆弱な2.1.285以前のままだと、この保護の隙は理論上の問題ではなく即座に実際のリスクになる。
なぜ安全チェックは、bash -c文字列の中で実際に実行されるコマンドを直接解析しないのですか？
これこそが、こうしたチェックメカニズムに共通する根本的な困難だ：shell文字列の中で実際に実行されるコマンドを解析することは、単に「プログラム名がrmかどうか」を比較することよりもはるかに複雑だ。bash -c文字列には変数展開、パイプ、条件分岐、入れ子になったサブシェルが含まれうる。「この文字列が展開された結果、最終的に危険なrmを実行するかどうか」を正確に判断することは、単純な文字列比較ではなく、完全なshell文法パーサーを実装することと実質的に同義だ。
これが、コマンド文字列の比較でリスクを判断するさまざまなツールでこの種の脆弱性が繰り返し発生しやすい理由でもある——開発者の見落としではなく、「任意のshell文字列を完全かつ正確に解析する」こと自体のエンジニアリングコストが非常に高いのだ。今回の修正が具体的にどう対処したかについて、公式は実装の詳細をあまり公開していないが、修正済みであることが確認されている事実から見て、少なくともこの特定のラッピング手法はチェックの対象範囲に含まれるようになったと言える。
npmのlatest、next、stableの3つのdist-tagのうち、日常的なインストールにはどれを選ぶべきですか？
この出来事はちょうど手頃な比較事例になっている：10月2日当日、latestとnextはすでに修正済みの2.1.288に更新されていたが、stableは3日前（9月29日）に公開された2.1.285のままだった。これは「stable」という名前が与える直感的な印象——より長く検証され、より信頼できるはず——と、「最新のセキュリティ修正を受け取っているかどうか」が必ずしも同期しているわけではないことを示している。
すべての状況に当てはまる単一の答えはない：ワークフローが高い安定性を要求し、セキュリティ修正が数日遅れて届くことを許容できるなら、stableに固定し続けるのも合理的だが、そのトレードオフが存在することを知っておくべきだ。セキュリティ修正をできるだけ早く受け取りたいなら、latestは通常stableより早く更新される。どちらを選ぶにせよ、実務上より重要な習慣は、タグ名だけを見て最新だと思い込むのではなく、定期的に実際にインストールされているバージョン番号を手動で確認することだ。
エンジニアではなく、社内の同僚のコンピュータにインストールされたClaude Codeのバージョン管理を担当しているだけです。これは私に実際どんな影響がありますか？
社内のツールインストールとバージョン管理を担当しているなら、この出来事は具体的なチェックリストを与えてくれる：まずチーム メンバーが現在インストールしているClaude Codeのバージョンが2.1.288以降かどうかを確認する。次に、自動化スクリプトやCIパイプラインで--permission-mode bypassPermissionsを使用している、またはshellの権限ルールを緩めているものがないかを確認する——これらのパイプラインは最もリスクが高く、最優先で更新すべき対象だ。
もう一つ覚えておく価値があるのは、チームのインストールスクリプトがstableタグに固定されている場合、それが常に「最新かつ安全」を意味するとは思い込めないことだ。今回の出来事は、まさにその3日間のギャップを実際に示した事例だ。より安全なやり方は、バージョン管理プロセスにもう一つのステップを加え、タグ名だけを信頼するのではなく、実際のバージョン番号を手動で確認することだ。
Claude Codeは、クリティカルパス（ファイルシステムのルート、/usr、/etc、ホームディレクトリ、作業ディレクトリとその上位ディレクトリ）を対象とするrm -rf系の削除コマンドに対して、「always-ask」という強制的な安全確認を課している。理論上は、どの権限モードを使っていても、こうしたコマンドは必ず最初に確認プロンプトを表示するはずだ。しかし、この保護には2026年9月23日に報告され、10月2日までの間修正されなかった迂回方法があった：rm -rfをbash -cやsh -cの文字列の中に包むだけで、このチェックは完全にそれを見失ってしまう。
問題は安全チェックの判断方法にある。このメカニズムが見ているのは「直接実行されるプログラム名」だ——rm -rf /を直接呼び出せば、プログラム名はrmであり、保護がトリガーされる。しかし同じコマンドをbash -c 'rm -rf /'やsh -c "rm -rf /"として包んだ場合、チェックが見る実行プログラム名はbashやshであり、実際に削除を行うrm -rf /は文字列引数の中に埋め込まれているだけだ。ある技術記事はこれを率直に述べている：「rmは文字列引数の中にあるため、チェックはそれを一切見ない」。
この脆弱性は少なくともv2.1.280から存在していた（Windows 10のGit Bash環境でテスト確認済み）、2026年9月23日に報告された。この脆弱性を悪用するには、次の2つの条件のいずれかが必要だ：--permission-mode bypassPermissionsフラグを使用している、または自分でshellの実行を許可するルールを設定している。デフォルトの対話モードを使い、毎回手動で承認しているユーザーは、この特定の問題の影響を受けない。
bash -cによるラッピングに加えて、別の、だが性質の似た迂回方法も存在した：/やホームディレクトリを対象とする危険なrmコマンドは、同じコマンドが~やワイルドカードパスへの出力リダイレクト構文（rm -rf / > ~/何らかのファイルのような構造）を同時に含んでいる場合も、本来あるべきalways-ask保護を失ってしまう。この問題はbash -cの迂回と合わせて、v2.1.288（2026年10月2日UTC 18:30にnpmへプッシュ）で修正された。
この脆弱性が修正されたことを知っていても、実際に修正を受け取れるかどうかは、Claude Codeをどのようにインストールしたかに依存する。報道によると、2026年10月2日UTC 21:05時点で、npmのlatestとnextの両方のdist-tagは修正済みの2.1.288を指していたが、stableタグは9月29日に公開された2.1.285のままだった——修正版から丸3リリース遅れていた。stableタグに固定してインストールしていたユーザーは、実際には脆弱なバージョンをそのまま実行しており、それを知らせる明確な表示は何もなかった。
まず、現在インストールされているバージョン番号を確認し、2.1.288以降かどうかをチェックする。npmでインストールし、特定のバージョンやタグを指定していない場合は、そのdist-tagが実際にどのバージョンに解決されているかを確認すること——「正式版をインストールしたのだから、最新の修正済みバージョンのはずだ」と思い込まないことだ。今回のギャップは、「stable」という名前自体が最新の修正を含むことを保証しないことを示している。次に、--permission-mode bypassPermissionsを使用しているか、あるいは設定でshell関連のaskルールを許可してより広い権限を与えていないかを確認する——どちらも当てはまらない場合、日常の対話モードでの手動承認がこの種のコマンドを既にブロックしているため、リスクは比較的低い。自動化パイプラインのために意図的にこれらの制限を緩めていた場合は、バージョンが更新済みかどうかを優先的に確認すべきだ。