OpenAI Codexで機密ファイルをうっかり除外できない問題が未解決のまま

OpenAI Codexを利用する際、意図しない機密ファイルまで読み込まれてしまう問題ですが、現在も根本的な解決策が見つかっておらず、未解決の状態が続いています。

今すぐできる対策としては、codexを実行しているユーザーが読み込めないようにファイルパーミッションを変更するか、それらのファイルをマウントしていないコンテナ内でcodexを動かすことだね。

そうしないと、エージェントが偶然ファイルをアップロードしてしまう可能性がある。もしモデルが「rg foo」を実行して、その中の一つのファイルに「foo」という文字列が含まれていたらどうなる？エージェントはツール出力をアップロードするから、そのファイルの中身まで含まれてしまうんだ。

結局のところ、解決策はcodexプロセスがそのファイルにアクセスできないようにすること、つまりコンテナを使うか、Unixパーミッションを設定するか、ファイルを削除するしかない。これらは今の時点ですでにできることだよ。

この問題が解決していないのは、みんなが「read」や「edit」ツールだけでなく、bashツールにもそれが適用されると期待しているからだろうね。それに、エージェントが「make」を実行した場合など、エージェントがそのファイルにアクセスできる必要もあるから、完璧に解決するのは不可能に近いよ。

怪しい話に聞こえるな。どうやって機能させるんだ？エージェントが開発しているアプリ自体がそのファイルにアクセスする必要がある以上、アクセスをブロックすることなんてできない。read_fileがアクセスできないからといって（たしか現在のハーネスはすでに.envファイルの読み込みを防止しているはずだけど）、モデルがその中身を絶対に見ないとは限らないだろ。

LLMの予測不能な性質を考えれば、こんな無意味な機能は実装されないでほしい。安心感を与えるだけで、実際はセキュリティなんてないようなものだから。そもそもこんなのどうやって強制するつもりなんだ？

みんなシステムが元々提供しているツール、つまりchmodの使い方を学ぶべきだよ。

.agentsignoreはセキュリティツールじゃないよ。

エージェントに対して「無視すべきファイル」を教えるヒントとしては良いアイデアだ（値がなくてトークンを消費するだけだからね）。

でも、機密情報の漏洩を防ぐためにこれを使うのは大きな間違いだ。エージェントがignoreファイルの内容を無視することを保証する手立てなんてないから。ハーネスによる制限だとしてもプロセス内で行われるものだから、悪意のあるエージェントなら簡単に回避できる。セキュリティを考えるならサンドボックスを使うこと。それ以外に道はない。

自分はAIサンドボックスを作っている（FOSSでずっと無料、持ち逃げなし）：https://github.com/kstenerud/yoloai

ユーザーのミスにしか聞こえないな。Codexは、実行されているホストやユーザーのコンテキストでシェルを使えるようにするツールだ。もし機密リソースがそのコンテキストでアクセス可能なら、それはユーザーの使い方が間違っている。もしコーディングエージェントを、自分と同じ権限でSSH接続している信用できない人間として扱っていたら、やり方を変えるだろ？

いずれにせよ、IssueのコメントやこのHNのスレッドに解決策は出ているよ。

LLMが賢いか馬鹿かはさておき、彼らはこうした制限を回避することにかけては非常に有能だよ。求められているのは開発中のコードのための.envファイルへのアクセス制限だろうけど、コード自体がアクセスできない（ファイルシステムやコンテナで隔離されている）なら何の意味がある？もし開発中のコードが環境変数を読み取るなら、Codexはどうやってメモリから値を読み取らずにデバッグするんだ？機能しないセキュリティ設定を追加するのは、ないよりもずっと悪い。

唯一保証に近いと言えるのは、完全にクリーンなVMをエージェントに渡し、必要な情報と権限だけを与えることだろうね。

私は「ワークスペース」のコンセプトを考えている。エージェントの会話ごとにクラウドVM全体を立ち上げ、ユーザーのローカル環境や信頼された他のコンテキストに触れずにコード変更を繰り返せる仕組みだ。エージェントの全ツールは特定のワークスペースGUIDが与えられた時だけ有効になる。この構成ではgitのようなCLIツールはリモートと通信できない。マシンはclone状態で初期化され、originと通信する方法はない。ハーネスにはVM内部にアクセスして、セキュアなコンテキストで確定的なPRを生成するために変更セットを取り出す専用メソッドがある（エージェントが「ReadyForReview」などを呼んだときなど）。

最近、私が職場でリモート/セキュアなdevcontainer内でエージェントを動かすために使っているツールをオープンソース化したよ。これを正しく解決するためにね：https://github.com/nvidia/rumpelpod

ここでも指摘されている通り、Issueで提案されているようなブロックリストが完全なものになることはまずない。機密データがあるなら、エージェントに直接マシンへの「yoloアクセス」を許可すべきじゃない。

Codexはクライアント・サーバーアーキテクチャのおかげで、リモートエージェントのハーネスとして特にうまく機能する。サーバーコンポーネントはコンテナ内（リモートかもしれない）で動き、クライアントはローカルで動く。だから、フロントエンドもリモートで動くclaude CLIなどと違って、プロンプトを書いたり編集したりする時にラグがないんだ。

Codexや他のコーディングエージェントがアクセスできるファイルは、「オプトアウト」ではなく「オプトイン」であるべきだ。
まともな（ワンクリックの）UXを求めるなら、Codexはこれを解決すべきレイヤーじゃないと思う。
私たちはClaudeとCodexを囲む独自の内部サンドボックスターミナルを作ったよ。ユーザーが設定した低リスクのコードと認証情報が入ったベースフォルダを、新しいセッションを作る前にサンドボックスへコピーするんだ。
他にもUXに関連する理由で独自のターミナルを作ったんだけど、興味がある人がいれば詳しく共有できるよ。

流出のリスクを避けるために、セキュリティ目的で.envを使うのはやめないといけない。リポジトリ作業で必要なAPIキーはssh-agentのようなプロキシで扱うべきだし、ベアラ認証よりも優れた仕組みが必要だ。