OpenAIのCodexプログラミングアシスタントは、ファイルの読み取り、コードリポジトリの編集、コマンドの実行、ユーザーのマシン上の開発ツールとの連携が可能です。これらの機能により長時間のエンジニアリングタスクで非常に実用的ですが、その安全性はユーザーが設定する権限とサンドボッ...
OpenAIのコーディングエージェント「Codex」は、ファイルの読み取り、コードリポジトリの編集、コマンドの実行、ユーザーのマシン上の開発ツールとの対話が可能です。これらの機能により長期的なエンジニアリング作業に適していますが、同時にその安全性はユーザーが選択する権限とサンドボックスの境界に大きく依存します。
AIBaseの報道によると、OpenAIはCodexがユーザーのホームディレクトリからファイルを削除した少数の事例を調査しました。この報道によれば、影響を受けたセッションは完全アクセス権限が有効で、サンドボックス保護なしで実行されていました。
AIBaseが報じた具体的な技術的説明では、一時ディレクトリのロジックと$HOME環境変数との間の誤った相互作用が関係しています。OpenAIは、この正確なプロセスを確認する公開ポストモーテムレポートをまだ公開していません。
OpenAIが公に確認している内容はより広範で、依然として重要です。公式のCodexドキュメントは、完全アクセス権限がプロジェクトディレクトリの境界を排除し、予期しない破壊的な操作を引き起こし、データ損失につながる可能性があると警告しています。
したがって、直接的な推奨事項は次の通りです。制限なしのアクセスが本当に必要で、別のレイヤーによる分離で保護されている場合を除き、Codexをサンドボックス化されたワークスペースに制限することです。
提供されたAIBaseレポートは、この問題を特定の設定の組み合わせで発生するものとして説明しています。
$HOME環境変数に関するエラーにより、ユーザーのホームディレクトリが削除対象と見なされたとされる。macOSとLinuxでは、$HOMEは通常、現在のユーザーのホームディレクトリを指します。このディレクトリには以下が含まれる可能性があります。
したがって、誤ったパスに対する再帰的な削除は、現在のアクティブなプロジェクトをはるかに超えた範囲に影響を与える可能性があります。
OpenAIの現在のWindowsサンドボックスドキュメントは、完全アクセス権限でCodexを実行すると、エージェントがプロジェクトディレクトリに制限されなくなり、データ損失につながる予期しない破壊的な操作を実行する可能性があると述べています。
OpenAIの権限ドキュメントは、3つの組み込み権限プロファイルを定義しています。
| 権限プロファイル | ファイルシステムの動作 | 適用シナリオ |
|---|---|---|
:read-only | ローカルコマンド実行は読み取り専用を維持 | リポジトリチェック、計画、レビュー |
:workspace | アクティブなワークスペースルートとシステム一時ディレクトリ内への書き込みを許可 | 通常のコーディングとリポジトリメンテナンス |
:danger-full-access | ローカルサンドボックス制限を削除 | 意図的かつ別途分離された制限なしアクセスの使用時のみ |
公式ドキュメントでは、以下のパターンが高リスクであると説明されています。
codex --dangerously-bypass-approvals-and-sandbox
エイリアスを使用しても同じ動作が可能です。
codex --yolo
これらのコマンドは、サンドボックスと承認プロンプトの両方を無効にします。これらは、推奨ではなく、ユーザーがこの危険な設定を識別して回避できるようにするためにリストされています。
OpenAIはこのパターンを、サンドボックスなし、承認なしとラベル付けし、通常の使用には推奨しないと述べています。
コーディングエージェントは単にコマンドを提案するだけではありません。ローカルエージェントモードでは、これらのコマンドを直接実行できます。
ワークスペースサンドボックスを使用する場合、オペレーティングシステムとCodexポリシーがコマンドの書き込み範囲を制限します。誤ったコマンドでも現在のプロジェクトを壊す可能性はありますが、無関係なディレクトリを恣意的に変更するべきではありません。
一方、完全アクセスを有効にすると、技術的な境界は存在しなくなります。モデルとそのシェルコマンドは、以下のものにアクセスできる可能性があります。
だからこそ、プロンプトの文言だけでは制御手段として不十分なのです。エージェントに「このフォルダだけを編集して」と指示するのは行動指示であり、サンドボックスは強制される境界です。
OpenAIは、サンドボックスと承認を補完的な制御手段と見なしています。
これら両方の制御を削除すると、最高リスクの設定になります。
承認プロンプトは、危険な操作が実行される前にリスクを捕捉できますが、ファイルシステムの分離に代わるものではありません。
ユーザーは誤ったコマンドを承認する可能性があります。自動レビューアも、承認システムを介して転送された操作のみを評価できます。
OpenAIのドキュメントは、自動レビューが、破壊的な操作、認証情報へのアクセス、データ窃取、持続的なセキュリティ弱体化など、対象となる承認リクエストに対してリスク分析を実行することを説明しています。
典型的な自動レビュー設定は次の通りです。
approval_policy = "on-request"
approvals_reviewer = "auto_review"
これにより、レビューレイヤーを維持しながら承認疲れを軽減できます。
しかし、Codexが承認とサンドボックスをバイパスするモードで起動された場合、レビューアは強制する権限の境界を持たない可能性があります。
より安全なモードは次の通りです。
OpenAIは、作業ディレクトリがバージョン管理されているかどうかに応じて、異なるデフォルト設定を推奨しています。
通常のリポジトリの場合、明示的なCLIコマンドは次の通りです。
codex --sandbox workspace-write --ask-for-approval on-request
ファイルをチェックするだけで編集しない場合。
codex --sandbox read-only --ask-for-approval on-request
これらの設定により、Codexは定義された実行境界内に制限され、ユーザーは特別な操作を承認できます。
OpenAIはまた、無人タスクのための妥協案を文書化しています。サンドボックスをアクティブに保ちながら、承認プロンプトを無効にすることができます。
codex --sandbox workspace-write --ask-for-approval never
このモードでは、Codexはワークスペースの制限内でタスクを最善を尽くして実行し、境界外の操作に対して権限を要求しません。これは、承認とサンドボックスの両方を無効にするよりもはるかに安全です。
ChatGPTデスクトップアプリ、Codex CLI、IDE統合では、具体的な制御方法は若干異なりますが、原理は同じです。
デスクトップまたはIDEインターフェースで、プロンプトコンポーザーの近くにある権限セレクターを開きます。
完全アクセスではなく、ワークスペース制限モードまたはデフォルトのサンドボックスモードを選択します。
Codexがアクティブなプロジェクトまたはワークスペースルート内でのみ書き込みを許可するモードを選択します。
CLIでは、以下を使用します。
codex --sandbox workspace-write --ask-for-approval on-request
なじみのないリポジトリを開くときは、最初に以下を使用します。
codex --sandbox read-only --ask-for-approval on-request
Codexにコードをレビューさせ、書き込み権限を付与する前に提案をさせます。
Codex
中では、使用状況や権限の画面で、どのディレクトリが書き込み可能なワークスペースルートと見なされるかを確認してください。
エディタに表示されているフォルダがエージェントがアクセスできる唯一のディレクトリであると想定しないでください。
追加のアクセス権限が必要なコマンドには、オンデマンド承認を使用します。
ワークフローの摩擦を減らすために、承認を完全に解除するのではなく、自動レビューを検討してください。
設定ファイルの変更は、実行中のプロセスを遡及的に制限できない場合があります。
設定を変更した後：
config.toml 設定Codexは以下のパスでの設定をサポートしています：
~/.codex/config.toml
既存のサンドボックス設定システムでは、より安全なデフォルト設定は以下の通りです：
approval_policy = "on-request"
sandbox_mode = "workspace-write"
より厳格なレビュー設定は以下の通りです：
approval_policy = "on-request"
sandbox_mode = "read-only"
サンドボックスを削除せずに自動レビューを追加することもできます：
approval_policy = "on-request"
sandbox_mode = "workspace-write"
approvals_reviewer = "auto_review"
OpenAIはまた、権限プロファイルシステムを新しいベータ版の設定システムとして文書化しています。シンプルなワークスペース設定は以下の通りです：
default_permissions = ":workspace"
読み取り専用のデフォルト設定は以下の通りです：
default_permissions = ":read-only"
設定に関する警告： OpenAIは、新しい権限プロファイルシステムが以前の
sandbox_mode設定と互換性がないことを指摘しています。どちらか一方のシステムのみを設定してください。
アイデアを一文で入力するだけで、We0 AI が紹介サイト、ページ、CMS を生成し、公開後の顧客獲得と流入拡大を支援します。
無料登録で完全なプロジェクトを 1 つ生成
1 つの完全な生成フローを試し、最初のプロジェクトのドラフトをすぐに確認するのに最適です。
それ以外は、両方のメソッドを同じアクティブな設定に配置し、それらが自動的に結合されることを期待しないでください。
.env ファイルを禁止する権限プロファイルシステムのベータ版をテストしているユーザー向けに、OpenAIは組み込みのワークスペース境界を拡張するカスタムポリシーを提供しています。
プロジェクト編集設定ファイルでは、ワークスペースを書き込み可能に保ちながら、環境ファイルへのアクセスを禁止できます：
default_permissions = "project-edit"
[permissions.project-edit]
extends = ":workspace"
[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"
[permissions.project-edit.network]
enabled = false
このポリシーは：
.env ファイルへのアクセスを禁止します。多くのローカルコーディングタスクにおいて、これはマシン全体への広範なアクセス権を付与するよりも良い出発点です。
組織は管理要件を使用して、ユーザーが無制限のサンドボックスモードを選択するのを防ぐことができます。
OpenAIは以下のような許可リストを示しています：
allowed_sandbox_modes = ["read-only", "workspace-write"]
これにより、管理環境においてフルアクセスが利用可能なサンドボックスオプションとして表示されなくなります。
新しい権限プロファイルシステムも集中制限の対象となります。管理者は承認済みのプロファイルを定義し、許可セットから :danger-full-access を除外できます。
これは、セキュリティポリシーが各開発者が正しいモードを選択することを覚えていることに完全に依存すべきではないため、有用です。
実用的なワークフローは、ホストシステム全体を公開することなく、Codexの速度の大部分を維持します。
プロジェクトディレクトリからCodexを起動します（関連のないプロジェクトを含むホームディレクトリや親フォルダからではありません）。
以下のような広範なパスの使用は避けてください：
~
または：
/
をアクティブなワークスペースとして使用します。
OpenAIは、作業をCodexに委任する前に、機能ブランチを使用し、git status をクリーンに保つことを推奨しています。
簡単な準備フローは以下の通りです：
git status
git switch -c codex/タスク名
git add -A
git commit -m "Codexタスク前のチェックポイント"
プロジェクトに応じてブランチ名とコミットメッセージを調整してください。
小さなコミットは、個々の変更の確認とロールバックを容易にします。
長時間の自律セッションの終了後に、最初の復元可能なチェックポイントを作成しないでください。
Codexの出力をプルリクエストとして扱います：
大規模なリファクタリング、依存関係の実験、ビルドシステムの変更、またはクリーンアップタスクには、エージェントをさらに隔離します。
オプションは以下の通りです：
OpenAIは、コンテナが次のように設計されている場合の安全な開発コンテナの例を提供しています。
外部隔離境界。
バージョン管理は追跡されたリポジトリファイルを保護しますが、コンピュータ上のすべてのファイルを保護するわけではありません。
Codexが同じユーザーアカウントまたはマウントされたファイルシステムを介して変更できないバックアップシステムを使用する必要があります。例としては、オフラインバックアップ、イミュータブルスナップショット、またはバージョン履歴をサポートするリモートバックアップサービスが挙げられます。
ファイルが削除されたばかりの場合、その後の書き込み操作により復元可能なディスクブロックが上書きされる可能性があります。
以下の予防措置を講じてください：
追跡されたソースコードの場合は、非破壊的なチェックから始めてください：
git status
git diff
git log --oneline --all
どのファイルとコミットがまだ利用可能かを確認するまでは、破壊的なGit復元コマンドを実行しないでください。
AIBaseのレポートによると、OpenAIはフルアクセスに関する警告の内容を更新し、保護措置を強化するとともに、より詳細なインシデント分析レポートを準備しています。
OpenAIの現在の公開ドキュメントには、フルアクセスがデータ損失につながる可能性があるという警告が明確に含まれており、サンドボックス境界、厳格な例外ポリシー、承認フロー、権限プロファイル、バージョン管理チェックポイント、および隔離された開発環境の使用が推奨されています。
本稿執筆時点では、$HOME ディレクトリの削除メカニズムというこの正確なイベントに関する公式の公開事後分析レポートはまだありません。
つまり、ユーザーは将来の説明を待つのではなく、現在利用可能な制御手段に依存する必要があります：
破壊的な動作は複数のレベルから発生する可能性があります：
クリーンアップスクリプトが誤ったディレクトリを指している。
そのため、セキュリティはモデルの精度だけに依存することはできない。
通常の編集、テスト、検索、およびローカルコマンドの実行は、通常ワークスペースの境界内で完了できる。
タスクが特定のディレクトリやネットワークターゲットへの追加アクセスを必要とする場合は、システム全体を公開するのではなく、正確な例外を追加することを推奨する。
自動レビューは承認リクエストの分類に役立つが、無制限の実行を無害にするわけではない。
サンドボックスは、コマンド自体にエラーがある場合でも実行可能な操作を制限できるため、ローカルにおける最も強力な制御メカニズムである。
Codexに書き込み権限がある場合、ファイルの編集や削除が可能である。ワークスペースモードでは、これらの操作は設定された書き込み可能なルートディレクトリに限定される。完全アクセスモードでは、ローカルサンドボックスの制限が解除され、誤ったコマンドの潜在的な影響が増大する。
$HOME削除の脆弱性を確認したか？提供されたAIBaseレポートは、その説明をOpenAIの調査に帰している。OpenAIの公開ドキュメントは、より広範な完全アクセス時のデータ損失リスクを確認しているが、2026年7月17日時点では、正確な$HOMEメカニズムを確認する公開された技術的事後分析は存在しない。
Codexがリポジトリの確認のみを必要とする場合は、:read-onlyモードを使用する。通常のコーディングには、オンデマンド承認と組み合わせた:workspaceまたはworkspace-writeモードが、生産性とセキュリティ制御の実用的なバランスを提供する。
--yoloは安全に使用できるか？--yoloは承認とサンドボックスをバイパスするエイリアスである。OpenAIはこれをサンドボックスなし、承認なしの高リスクモードと説明しており、重要なファイルを含む通常のホスト上で使用すべきではない。
可能である。OpenAIのドキュメントは、--ask-for-approval neverがサンドボックスモードと互換性があることを示している。例えば、codex --sandbox workspace-write --ask-for-approval neverは、ワークスペースの境界を維持しながら、インタラクティブな承認プロンプトを回避する。
できない。Gitは追跡されコミットされたリポジトリファイルを復元できるが、追跡されていないファイル、認証情報、個人文書、外部データベース、無関係なフォルダを自動的に保護することはできない。バージョン管理で安全に保管されていないデータについては、独立したバックアップ計画を使用すること。
ならない。自動レビューは条件を満たす承認リクエストを評価し、サンドボックスはファイルシステムとネットワークの境界を強制する。可能な限り、一方を他方の代わりと見なすのではなく、両方の制御を維持すべきである。
コンテナや仮想マシンが外部セキュリティ境界として意図的に設計され、機密性の高いマウントデータを含まない場合、これは妥当である。マウントポイント、認証情報、ネットワークアクセス、ホスト統合を慎重に確認すること。完全アクセスモードは、その環境内でアクセス可能なすべてのものを依然として破損または漏洩させる可能性がある。
Agent Approvals and Security：サンドボックスモード、承認ポリシー、自動レビュー、危険な設定に関する公式ガイド。
報告されたCodexのファイル削除インシデントは、最高リスクの実行条件下で発生した：完全アクセスかつサンドボックス境界なし。AIBaseは$HOMEに関連すると思われるクリーンアップの失敗を説明し、OpenAIの公開ドキュメントはより広範な事実、すなわち、無制限のアクセスが意図しない破壊的な操作やデータ損失を引き起こす可能性があることを確認している。
ほとんどの開発者にとって、通常のコードリポジトリ作業には完全アクセス権は必要ない。ワークスペース制限付き書き込み、オンデマンド承認、バージョン管理チェックポイント、隔離環境は、Codexの中核的なコーディング能力を損なうことなく、より安全な実行モードを提供する。
無人タスクを実行する際、ユーザーはワークスペースサンドボックスを維持しながら承認プロンプトを無効にできる。これは両方の保護層を迂回するよりもはるかに安全である。
実用的なルールは簡単である：Codexにはマシン全体ではなく、必要なプロジェクトへのアクセス権のみを付与すること。
