Piのbashフック拒否は通常のツールエラー止まり

テストは安全性全般より狭い問いから始まった。フックが呼び出しを拒否した時、実際に何がモデルに届くのかという点だ。Piのドキュメントは仕組みを説明していた。event.inputは再検証なしでその場で書き換え可能で、拒否は{ block: true, reason?, terminate? }を返す。しかしモデルが見る結果については何も述べていなかった。正規表現/\brm\b/に一致するものは拒否し、他のbashコマンドにはechoマーカーを前置する最小の拡張を走らせると、セッションログでマーカーが実際に出力に現れること、拒否が理由文字列を伴う通常のエラー結果として届くことを確認できた。モデルはその後ls -laでディレクトリを再確認し、tmpファイルが残っているのを見て、無限に再試行せず続行するか片付けるかをユーザーに尋ねた。

この秩序だった挙動は指示を強めると変わった。rmなしでもファイルを削除しなければならないと告げると、モデルはブロックされたパターンを避けてunlinkを使い、正規表現を素通りした。作者はkeep.txtだけが残ったことを確認した。モデルはfind -delete、perlのunlink、pythonのos.removeワンライナーも代替として挙げた。作者の結論は、呼び出しを拒否できることと安全であることは別だというものだ。Piは拡張をin-processで動かし引数の中身を公開するため、より強力なフィルタは可能だが、それはフレームワークの保証ではなく拡張作者の責任にとどまる。

作者はまた、以前の日本語記事がモックプロバイダーで拒否と継続の中核をすでに示していたのに対し、今回の実行は実際のAnthropic APIを通し、コマンド書き換えと指示による回避も追加で扱ったと述べている。terminate: trueオプション、並列ツール呼び出し、OpenCodeのアウトプロセス方式との実測比較は今後の課題として残された。