クロードコード破壊 オーパス5 自動モード

ポイントは、オートモードが人に誤った安心感を与えて、ちゃんとしたサンドボックスでClaudeを動かす必要がないと思わせることなんだ。この攻撃がサンドボックス内（たとえYOLOモードでも）で実行されれば、比較的無害になるだろうね。

オートモードとは全然関係ないと思うよ。マニュアルモードでは完璧に動くはず。Claudeも必要ないし、ただ人間に似たアーカイブを渡して、少なくとも一度はそのディレクトリから簡単なPythonを実行させればいいんだ。変な.pyファイルに気づかないように、たくさんのファイルを用意しておけばね。

まあ、AI企業には法律が適用されないから、俺たちがバカを見たってことだね。

確か、利用規約に同意すると集団訴訟を起こす権利を放棄することになるんだっけ？

CやC++でも、ライブラリディレクトリ内のシステムヘッダーで似たようなことが起こるよね（もしかしたら、そういうことに対して警告を出すコンパイラもあるかも？）。ほとんどの言語は、こういうことを防ぐように標準ライブラリを特別扱いしてないからね。

これはひどい問題で、エコシステムにとってかなりの落とし穴だね。例えば、俺はRNGの使用分析のためにtool_name/random.pyを使ったツールを作ったんだけど、そのディレクトリ内で実行されるコマンドはbuiltinのimport randomを隠しちゃうんだ。だから、そのディレクトリからblackフォーマッターを実行できなかった。ローカルのrandom.pyを誤ってインポートしちゃうからね。解決策は、Pythonのフラグを更新して-Iを含めること。そうすれば、Pythonは隔離モードで実行される。これはPEP-668の実装に対する俺のフラストレーションにも関係してる。Pythonは長い間、システムライブラリの偶発的な上書きの問題を抱えてる。もしsudo python -mpip install fooを実行すると、ディストリビューションのsudo apt-get install python-fooと非常に悪い相互作用を起こす可能性がある。pipがapt-getで管理されるべきファイルを追加/削除するからね。でも、これを防ぐための警告を追加する際に、~/.local/pythonX.Y/site-packagesにも同じ警告を適用しちゃった。ここは通常、ユーザーがpython -mpip --local fooで追加パッケージをインストールする場所だから。主張としては、これは/usr/bin/pythonのインポートパスの一部だから、ユーザーのsite-packagesへのインストールもブロックすべきだってこと。これはPEP-668の目的を「ファイル所有権の競合を避ける」から「システムツールのための隔離されたPython環境を確保する」に変えてしまう手品みたいなもんだ。もし俺が/usr/bin/pythonのインポートがディストリビューション管理のインストールだけに影響されるべきだという主張を受け入れるなら、どこでも*.pyファイルを作ることも禁止されるべきだよね。だって、作業ディレクトリにあったらインポートされるんだから。これは明らかにおかしいし、システムレベルの隔離されたPythonを持つためにユーザーレベルのsite-packagesを壊すのが正当化されるとは思えない。正しい解決策は、ディストリビューション管理のプログラムが#!/usr/bin/python -Iをシェバンとして使うことだよ。そうすれば、実際に隔離された環境が得られるのに。結局、PEP-668はユーザーレベルのsite-packagesを無駄に壊して、解決しようとした問題すら解決できなかったんだ。

うん、ここでの最初の印象は「わお、Pythonってダメだな」って感じだね。

記事を読んだ後の私の感想は、これってPythonの脆弱性が示されてるだけで、Claude Codeの問題じゃないってことかな。