OpenAI、Codexのセキュリティ保護を強化——より安全なクリーンアップと権限制御で破壊的な操作を防止

OpenAI、Codexのセキュリティ防御を強化—破壊的操作を防ぐためのクリーンアップと権限制御メカニズムを新設

OpenAIは、ユーザーの意図を超えた破壊的操作の報告を調査した後、Codexのセキュリティ制御メカニズムをアップグレードしました。

問題は、AIプログラミングエージェントがコマンドを実行できること自体ではありません—これこそがCodexの中核的価値です。リスクが生じるのは、広範な権限を持つエージェントがクリーンアップやファイル管理操作を実行する際に、ターゲットパスを誤って解釈した場合です。

OpenAIのCodexエンジニアリング責任者であるThibault "Tibo" Sottiaux氏によると、同社はCodex内で要求範囲を超えた破壊的操作を実行した少数のGPT-5.6の事例を調査しました。繰り返し見られたパターンの1つは、一時ディレクトリのクリーンアップ、特に広範なアクセス権限と少ないサンドボックス保護でセッションを実行した場合に関係していました。

OpenAIの最新の緩和策は、複数のレベルから同時に取り組んでいます：

• 破壊的操作の前に削除ターゲットを検証
• リスクの高い環境変数を再利用する代わりに、専用の一時ディレクトリを使用
• 高リスクコマンドの検出と審査を強化
• 「フルアクセス」モードを誤って有効化しにくくする
• 破壊的操作をより確実に識別できるよう自動審査機能を改善
• チームが観察した失敗事例に基づく新しい評価とトレーニングタスクを追加

重要な変更は、単一の禁止リストではありません。OpenAIは、モデルの指示とその周囲の実行環境の両方を同時に強化しています。

調査は一時ディレクトリのクリーンアップに焦点

OpenAIの調査により、一部の破壊的障害が一時作業ディレクトリのクリーンアップロジックに関連していることが判明しました。

プログラミングエージェントは作業中に一時的な場所を作成することがよくあります。タスクには、アーカイブファイルの解凍、中間ファイルの生成、テストの実行、パッチのステージング、使い捨てのビルド成果物の作成が含まれる場合があります。これらのファイルを後でクリーンアップすることは通常安全です。

一時ディレクトリを識別する変数があいまいであったり、再利用されたり、形式が正しくなかったり、予期せず重要な場所を指していたりすると、危険が生じます。

Sottiaux氏は、ある失敗パターンを次のように説明しました：モデルがシステム環境変数（$HOMEなど）を一時作業ディレクトリとして再利用するケースです。その後のクリーンアップコマンドがその変数を誤って解釈した場合、一時ディレクトリを削除することを意図したコマンドが、ユーザーの実際のホームディレクトリを指し示す可能性があります。

この障害の連鎖は、高レベルでは次のように理解できます：

一時作業スペースを作成または識別
↓
広範なシステム変数を再利用
↓
クリーンアップコマンドを構築
↓
誤ったターゲットパスを解析
↓
広範な権限で破壊的操作を実行
↓
想定範囲を超えたファイルを削除

制限のないセッションでは、このリスクは特に深刻です。

厳密に限定されたサンドボックス環境では、オペレーティングシステムが誤ったコマンドが無関係なディレクトリに到達するのを防ぐことができます。フルアクセスモードでは、この境界が意図的に除去されているため、パス解析エラーがより大きな影響範囲を持つ可能性があります。

OpenAIの現在のCodexドキュメントはこの違いを明確にしています：通常のworkspace-writeモードは日常的な編集を現在のワークスペース内に制限しますが、

danger-full-accessはファイルシステムとネットワークのサンドボックス境界を除去します。

Codexは破壊的ターゲットをより明確にチェックするようになった

最初の主要な緩和策は、削除や類似の破壊的操作の前に行う、より強力なターゲット検証です。

Codexはクリーンアップを日常的な最終ステップとは見なさなくなり、ターゲットパスが実際に変更しようとしているパスであることを確認するよう明確に指示されています。

これは、破壊的なシェルコマンドが通常、引数が正しい場合にのみ安全であるため、重要です。

たとえば、専用の一時ディレクトリの削除と親ワークスペースの削除の違いは、誤った変数展開、引用エラー、パス正規化の問題、または引数の欠落によるものかもしれません。

新しいアプローチは、暗黙の前提への依存を減らします。

高リスクのファイルシステム操作を実行する前に、システムは以下のことをより慎重に検討する必要があります：

• このコマンドは正確にどのディレクトリに影響を与えるのか？
• そのディレクトリはこのタスクのために作成された一時的な場所か？
• パスは意図したワークスペース内に解決されるか？
• ターゲットが予期せず広すぎないか？
• 削除は不可逆的か？
• ユーザーに尋ねることなく続行できるほど範囲が明確か？

これはエージェントの行動レベルのセキュリティ改善です。

サンドボックスの代わりにはなりませんが、危険なコマンドがそもそもサンドボックス境界に到達する可能性を低減します。

専用の一時ディレクトリがリスクのある変数再利用に取って代わる

OpenAIはまた、Codexが一時作業を処理する方法を変更しています。

すでに重要な意味を持つシステム変数を再利用する代わりに、新しい専用の一時ディレクトリを作成する方がより安全なパターンです。

$HOMEのような変数は、プロジェクトファイル、設定、認証情報、アプリケーション状態、その他の個人データを含む実際のユーザーディレクトリを通常指すため、特に機密性が高いです。

専用の一時パスを使用することには2つの利点があります。

まず、ターゲットの意味論的範囲がより狭くなります：使い捨てのタスクデータのみに使用されます。

次に、システムが削除ターゲットをタスクの初期に作成された正確な一時ディレクトリと比較できるため、クリーンアップの検証が容易になります。

これは直接的なエンジニアリング原則ですが、自律エージェントがマシン速度でシェルコマンドを実行できる場合、その重要性はさらに高まります。

より安全なパターンは実際には次のとおりです：

新しい一時ディレクトリを作成
↓
タスク固有の一時ファイルをそこに保存
↓
正確なパスを追跡
↓
クリーンアップ前に同じパスを検証
↓
検証された一時ディレクトリのみを削除

目標は、広範な環境状態をクリーンアップのターゲットにしないことです。

危険なコマンドの検出と審査が強化されている

パス検証は防御の1つの層にすぎません。

OpenAIはまた、リスクのあるコマンドを識別して審査に回すメカニズムも強化しています。

Codexの変更ログには、強制rm操作に対するより強力な検出と、より一貫性のあるフルアクセス確認がすでに記録されています。現在の自動審査ポリシーはまた、実質的な不可逆的損害のリスクを伴う破壊的操作を、阻止しようとするカテゴリに明確に含めています。

これが重要なのは、コマンドが構文的に完全に合法であっても、安全ではない可能性があるからです。

削除コマンドはシェル構文規則に完全に準拠しているかもしれませんが、それでも次の理由で危険な場合があります：

• ターゲットディレクトリの範囲が広すぎる
• ワークスペース外のデータに影響を与える
• 未解決の変数を使用している
• 大規模なディレクトリツリーを再帰的に削除する
• コミットされていない作業成果を破壊する
• セキュリティ制御を弱体化させる
• 複数の危険な操作を1回のシェル呼び出しに結合する

したがって、OpenAIの更新されたセキュリティ防御は、コマンドが実行できるかどうかだけでなく判断しません。

現在の権限とユーザー認可の下で、このコマンドが実行されるべきかどうかも判断します。

フルアクセス権限は誤って有効化されにくくなった

原文では、Codexのフルアクセス権限エクスペリエンスの変更にも焦点が当てられています。

フルアクセスは意図的に非常に強力に設計されています。OpenAIの現在の権限ドキュメントによると、このモードでは、Codexはコンピューター上の任意のファイルを編集でき、承認を求めることなくネットワークアクセスを持つコマンドを実行できます。

これは、一時的な仮想マシン、専用開発環境、またはオペレーターが意図的に無制限の自動化を望むその他の厳重に管理されたシステムで役立ちます。

しかし、通常のワークステーションでは、このモードはミスの結果を大幅に増大させます。

OpenAIは現在、このモードを有効化するためのハードルを高くしています。

現在のCodexドキュメントでは、フルアクセスは、オプションの権限モードとして表示される前に、まずデスクトップアプリの設定で明示的に有効化する必要があると規定されています。インターフェースには、データ損失、漏洩、予期しない動作が発生する可能性についてのより強力な警告も表示されます。

承認された高リスクセキュリティモデルについては、OpenAIはデスクトップアプリがフルアクセスの有効化前に、そのモデルに対する追加の警告を表示し、より安全な「代わりに承認」モードを推奨すると述べています。

主要な権限モードの説明

重要な点：自動審査とフルアクセスは同じではありません。

自動審査はサンドボックスメカニズムを保持します。変更されるのは、サンドボックス境界を越えるリクエストを誰が評価するかです。

フルアクセスはサンドボックス境界自体を直接除去します。

自動審査は破壊的操作をより厳格に識別するようになった

OpenAIは、破壊的な操作をより適切に特定するために、自動審査ルールも更新した。

自動審査は独立した審査エージェントであり、メインのCodexエージェントがサンドボックス境界を越えようとするときに、対象となるリクエストを評価する。

通常のフローは以下の通りである：

メインのCodexエージェントがサンドボックス内で作業する
↓
ある操作に追加の権限が必要になる
↓
Codexが承認リクエストを作成する
↓
自動審査がそのリクエストを評価する
↓
承認 → 実行を継続
拒否 → Codexはより安全な経路を探すか、ユーザーに問い合わせる必要がある

OpenAIのドキュメントによると、自動審査は以下に関わるリクエストを評価できる：

• 昇格したシェルまたは実行権限；
• ブロックされたネットワークアクセス；
• 書き込み可能なルートディレクトリ外への変更；
• 副作用を生じる外部MCPまたはアプリツールの呼び出し；
• 新しいウェブサイトやドメインへのコンピュータ使用アクセス。

そのポリシーは、認証情報の探索、データ漏えい、セキュリティ制御の持続的な弱体化、および重大な不可逆的損害のリスクを伴う破壊的行為を含むリクエストを拒否または制限することを目的としている。

これにより、自動審査はユーザーにとって重要なセキュリティ層となり、手動介入を減らしつつ、メインのコーディングエージェントに無制限のアクセス権を与えることはない。

しかし、OpenAIは明確に、自動審査はサンドボックスメカニズムの代替にはならないと述べている。

ユーザーが完全アクセスを選択してサンドボックスを削除した場合、自動審査器はもはや存在しない境界を再作成することはできない。

OpenAIは新しい評価で障害を再生している

緩和策はモデルのテストにも反映されている。

ソティオ氏によると、OpenAIは調査中に発見されたさまざまな種類の障害を再生する、対象を絞った評価を構築した。同社はまた、これらのリスクに対する強化学習タスクとスコアラーも増やしている。

これは重要である。なぜなら、まれな破壊的エラーが孤立したケースとしてのみ評価される場合、改善が難しいからである。

実際の障害を再現可能なテストに変換することで、チームは以下のような問いを立てることができる：

• モデルは、意図せず大きすぎる削除対象を認識できるか？
• 機密性の高い環境変数の再利用を避けるか？
• スコープが不明確な場合、操作を停止するか？
• 可能な場合に回復可能な操作を優先するか？
• 自動審査はその操作を適切にエスカレーションまたは拒否するか？
• 将来のモデルが同じ障害を繰り返すか？

言い換えれば、このイベントは回帰テストのカバレッジに変換されている。

セキュリティ目標は、単にコマンドパターンを修正することではなく、将来のCodexバージョンがより広範なカテゴリの障害を再現する可能性を低くすることである。

サンドボックスと権限は、依然としてプロンプトそのものより重要である

調査はまた、コーディングエージェントのセキュリティに関するより広い見解を強化した。

「ファイルを注意深く扱う」のような自然言語の指示は、強力なセキュリティ境界ではない。

実行サンドボックスこそが、それである。

OpenAI自身の導入ガイドラインは、サンドボックスと承認を補完的な管理策として説明している：

• サンドボックスは、Codexが書き込める場所とアクセスできるネットワークリソースを決定する；
• 承認ポリシーは、Codexがその境界を越える前にいつ停止しなければならないかを決定する。

ほとんどのローカル作業では、OpenAIは現在、無制限の実行ではなく、ワークスペーススコープの設定を推奨している。

代表的な、より安全な設定は以下の通りである：

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"

自動昇格審査を使用したいユーザーは、同じサンドボックスを維持しつつ、レビューアーを変更できる：

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "auto_review"

これらの設定は、通常のワークスペースの周囲にOSレベルの境界を維持する。

対照的に、完全アクセスは意図的にその保護を削除し、環境自体が必要な分離を提供する場合にのみ使用すべきである。

今回のCodexセキュリティ強化は開発者にとって何を意味するか

開発者にとって、この更新はCodexが破壊的なエラーを決して起こさないことを意味するわけではない。

OpenAI自身のドキュメントは、自動審査は誤る可能性があり、エージェントレベルのセキュリティメカニズムは回復可能な開発プラクティスの代替と見なされるべきではないと警告している。

実際の変更は、多層防御である。

高リスクの操作は、現在、ブロックされる機会が増えている：

1. モデルはターゲットを検証するように指示される。
2. 一時的な作業は、より安全な専用パスを使用することが期待される。
3. 高リスクのコマンドパターンは、実行フレームワークによって識別され得る。
4. サンドボックス境界は、ワークスペース外へのアクセスをブロックできる。
5. 承認または自動審査は、境界を越えるリクエストを評価できる。
6. 完全アクセスには、より明確で慎重なユーザー操作が必要である。
7. 障害ケースは評価と将来のトレーニングに追加される。

これは、単一のセキュリティ対策に依存するよりもはるかに堅牢である。

日常的なコーディングでは、最も安全なデフォルト設定は依然として単純である：タスクが本当により広いアクセス権を必要としない限り、エージェントをワークスペース内に留めておくこと。

よくある質問

Codexがターゲットディレクトリ外のファイルを削除することがあるのはなぜか？

OpenAIの調査では、一時ディレクトリのクリーンアップに関連する障害モードが発見された。特定の状況では、$HOME などの広範なシステム変数が一時的な作業で再利用される可能性があり、形式が正しくないクリーンアップパスは、一時ディレクトリではなく実際のユーザーデータを指す可能性がある。

調査後、Codexにどのような変更があったか？

OpenAIによると、Codexは現在、削除ターゲットをより明示的にチェックし、より安全な一時ディレクトリパターンを使用し、破壊的操作の検出を強化し、自動審査を改善し、完全アクセスが誤って有効になりにくくしている。同社はまた、観察された障害に基づいて対象を絞った評価を作成した。

Codexの完全アクセスとは何か？

完全アクセスは通常のサンドボックス制限を削除し、Codexがファイルを広範囲に編集し、通常の承認境界なしにネットワークアクセスを持つコマンドを実行できるようにする。OpenAIは、これがデータ損失、漏えい、予期しない動作のリスクを大幅に増加させると警告している。

自動審査は完全アクセスと同じか？

異なる。自動審査は既存のサンドボックスを維持し、対象となる昇格リクエストを審査エージェントに送信する。完全アクセスはサンドボックス境界を削除するため、2つのモードが提供する保護レベルは大きく異なる。

自動審査は破壊的なコマンドをブロックするか？

OpenAIの現在のポリシーによると、自動審査は、重大な不可逆的損傷のリスクを伴う破壊的操作、および認証情報の探索やデータ窃取などのリスクを特定しブロックすることを目的としている。これは、現在のサンドボックスおよび承認ポリシーの下で既に承認を必要とする操作のみを審査する。

ほとんどのCodexユーザーはどの権限モードを選択すべきか？

OpenAIは、ほとんどのローカル作業が通常の承認ベースのモードから始めることを推奨している。これにより、ワークスペース内での通常の編集が可能になり、Codexがその境界を越えるか制限されたリソースにアクセスする前に審査が要求されるようになる。

これらの変更後もCodexは誤りを犯すか？

犯す。これらの対策はリスクを低減するが、ゼロエラー動作を保証するものではない。バージョン管理、バックアップ、狭いワークスペース権限、および高リスク操作への意図的な承認は、依然として非常に重要である。

Codexの権限とサンドボックス設定はどこで確認できるか？

ChatGPTデスクトップアプリまたはIDE拡張機能では、タスクに関連付けられた権限制御を使用する。Codex CLIでは、/permissions が利用可能なモードを表示し、公式設定ドキュメントが sandbox_mode、approval_policy、approvals_reviewer を説明している。

関連ツール

• OpenAI Codex：ローカル、IDE、デスクトップ、クラウドワークフロー向けの公式Codexドキュメント。
• Codex CLI：OpenAIのオープンソースコマンドラインコーディングエージェントとそのリリース履歴。
• Codex 権限：「承認リクエスト」、「自動審査」、「完全アクセス」および関連する権限モードに関する公式説明。
• Codex 自動審査：サンドボックス境界を越える承認リクエストの自動審査に関するドキュメント。
• Codex サンドボックス化：

read-only、workspace-write、danger-full-access の公式リファレンスです。

• Codex ルール：選択されたコマンドパターンを許可、プロンプト表示、またはブロックするためのコマンドポリシー制御です。

関連リンク

• Thibault Sottiaux による Codex セキュリティアップデート：調査の経緯と新たに発表された緩和策を説明する OpenAI Codex のエンジニアリングアップデートです。
• OpenAI で Codex を安全に実行する：サンドボックス化、承認、ネットワーク制御、ホスティング構成、監査可能性に関する OpenAI の概要です。
• エージェントの承認とセキュリティ：サンドボックス境界、承認ポリシー、保護されたパス、自動承認レビューに関する詳細なガイドです。
• Codex 自動レビュー：トリガー条件、レビュープロセス、破壊的操作ポリシー、失敗時の動作を網羅した公式ドキュメントです。
• Codex 権限：ユーザー向け権限モードと完全アクセス警告に関する公式の説明です。
• Codex 更新ログ：より強力な強制 rm 検出、完全アクセス確認、および関連するセキュリティ改善を記録したリリース履歴です。
• OpenAI Codex GitHub リポジトリ：ソースコード、課題、リリースノート、およびオープンソースの Codex CLI 実装です。

まとめ

少数の破壊的なクリーンアップ操作がユーザーの想定範囲外のファイルに影響を与えた稀なケースを調査した後、OpenAI は Codex を強化しました。主な障害モードは、一時ディレクトリの処理、過度に広い環境変数、ターゲット検証の不十分さ、そして権限が広すぎるために誤ったコマンドが重大な損害を引き起こす可能性のあるセッションに関係していました。

新しいセキュリティ対策により、ターゲットパスのチェック、より安全な一時ディレクトリの処理、破壊的コマンドのレビュー強化、完全アクセス警告の明確化、および改善された自動レビューポリシーが追加されました。OpenAI はまた、観察された

失敗を反復可能な評価およびトレーニングタスクに変換しています。

これらの変更により、コーディングエージェントが通常のクリーンアップエラーを大規模なファイルシステム事故に発展させる可能性は低減しましたが、制限のない実行がリスクゼロになるわけではありません。

ほとんどのローカル開発において、最も安全な方法は依然是 Codex を作業スペースのサンドボックス内に維持し、タスクで本当に必要な場合にのみ権限を昇格させることです。