AGENTS.mdだけでは危ない──Codex Permission Profilesの仕組み

Codexにどこまでの操作を任せるか、多くの人はAGENTS.mdへの指示や口頭のプロンプトで制御しようとする。しかしOpenAI公式ドキュメントが定義するPermission Profilesは、それとは別の層——ローカルコマンドが実行時に強制されるサンドボックス境界を指す機能だ。2026年8月27日時点でOpenAI公式ドキュメントには「Beta. Permission profiles are under active development and may change.」と明記されている。この記事は公式原文だけを根拠に、仕組みと見落としやすい注意点を整理する。

• Permission Profilesは、ファイルシステムルール＋ネットワークルールを組み合わせた名前付きポリシー。組み込みは:read-only/:workspace/:danger-full-accessの3つで、古いサンドボックス設定(sandbox_mode)とは併用不可
• network.enabled = trueを設定しても、ネットワークプロキシ自体は起動しない。ドメイン許可リストを実際に強制するにはfeatures.network_proxy = trueが別途必要で、プロキシが動いていなければドメインルールは効かない
• 混在バージョンの組織展開では、管理者がallowed_sandbox_modesを一時的な互換制約として残せる。ただしこれは全クライアントがCodex 0.138.0以降になるまでの暫定措置と明記されている

3つの組み込みプロファイル

Codexには3つの組み込みプロファイルが用意されている。

トップレベルのdefault_permissionsキーに、これらのいずれか、または[permissions.<name>]で定義した独自プロファイル名を指定して使う。エンタープライズ管理者はallowed_permission_profilesをmanaged requirements.tomlに設定することで、ユーザーが選べるプロファイルを制限できる。一度この設定を入れると、明示的に許可していないプロファイルはすべて拒否される——将来のCodexバージョンで追加される組み込みプロファイルも含めて、である点が明記されている。

古いサンドボックス設定とは併用できない

見落としやすい仕様として、公式ドキュメントは「Permission profilesは古いサンドボックス設定と組み合わせては使えない」と明記している。default_permissionsと[permissions]を使うか、sandbox_mode／sandbox_workspace_writeを使うか、どちらか一方を選ぶ必要がある。読み込まれたどこかの設定ファイルにsandbox_modeがあれば、--sandboxフラグを渡した場合でも、選択した設定プロファイルがsandbox_modeを設定していれば、Codexはそちらの古い設定を優先して使う。例外はmanaged allowed_permission_profilesで、これが設定されている場合はCodexがPermission Profilesを使う側に強制される。

ネットワークルールは「プロキシが動いていて初めて」効く

これはドキュメントが太字で強調している重要な注意点だ。プロファイルのnetwork.enabled = trueはコマンドのネットワークアクセスを許可するだけで、ネットワークプロキシそのものは起動しない。 プロファイルのドメインルールを実際に強制するには、config.tomlでfeatures.network_proxy = trueを別途設定するか、管理者が有効化した[experimental_network]の要件を使う必要がある。プロキシが動いていない状態では、プロファイルのドメインルールは直接のネットワークアクセスを制限しない。

ドメインルールの書式と、見落としやすい既定挙動

公式ドキュメント「Permissions」のリファレンス表を確認すると、[permissions.<name>.network]まわりの設定はかなり細かく規定されている。実務で押さえておくべき点を抜き出す。

「ネットワークを有効にしただけでは何もかも開く」わけではなく、むしろ既定側は閉じる方向に倒されている、というのがこの表から読み取れる設計思想だ。特に「localhostですら明示的な許可がいる」という点は、ローカルの開発サーバーにComputer Useやテストツールから繋げようとして初めてハマりやすい落とし穴だと考えられる。

Codex cloudのネットワーク既定は、また別の話

ローカルのPermission Profilesとは別に、Codex cloud（クラウド実行環境）のネットワーク制御は独立した仕組みだと公式ドキュメント「Internet access」に明記されている。Codexは既定でエージェントフェーズ中のインターネットアクセスをブロックする。ただしセットアップスクリプトの実行中は依存関係のインストールのためにインターネットアクセスが有効なままで、環境ごとにエージェントのインターネットアクセスを有効化するかどうかを選べる。ローカルのPermission Profilesがデフォルトで「許可リストが空なら全部ブロック」という設計だったのと同じ方向性で、Codex cloudも「エージェント本体は既定でネット遮断、セットアップだけ例外」という閉じた既定値を採用している。

extendsで組み込みプロファイルを土台にする

ゼロから書くより、組み込みプロファイルや既存の名前付きプロファイルをextendsで拡張することが推奨されている。たとえば:workspaceを拡張すると、ワークスペースルート内の.codexディレクトリが読み取り専用のまま引き継がれる——明示的に上書きしない限り、ベースラインの保護がそのまま残る仕組みだ。

プロファイルが制御しない領域

公式ドキュメントの「Scope and enforcement」節は、Permission Profilesがローカルのサンドボックス化されたコマンド実行だけを対象にすると明記している。以下は別の制御系統を使う必要がある。

• Web検索：web_search・allowed_web_search_modesで制御。tools.web_search.allowed_domainsは検索結果をフィルタするだけで、コマンドのネットワークアクセスは制御しない
• コネクタ／アプリ：それぞれ独自のサービス側接続・ワークスペース権限を使う
• MCPサーバー：mcp_servers設定と管理者側の許可リストで制御
• ブラウザ・Computer Use：独自の機能・承認コントロールを使う
• Codex cloud：環境ごとのinternet access設定を使う

つまり、コマンドのネットワーク許可リストを設定しただけでは、Codexが行うすべての操作をカバーする「グローバルなネットワークポリシー」にはならない。各機能を個別に設定する必要がある。

プラットフォームごとに強制方法が違う

公式ドキュメントは、強制方法がOSによって異なることも明記している。

• macOS：Seatbeltサンドボックスプロファイルを使用。選択したポリシーがプラットフォームで強制できない場合、Codexは「サンドボックスなしで黙って実行する」のではなく実行そのものを拒否する
• Linux／WSL：bubblewrapとseccompを使用。Landlockは互換性のためのフォールバック経路として利用可能
• ネイティブWindows：elevatedサンドボックスが最も強力（低権限の専用サンドボックスユーザー・ファイルシステム権限境界・ファイアウォールルールを利用可能）。unelevatedはネットワーク分離が弱いフォールバックで、一部の読み書き分割を強制できない場合はそのポリシー自体が拒否される。Linuxサンドボックスモデルが必要な場合はWSLの利用が案内されている

ベータ機能ゆえ仕様は今後変わりうる

限界を先に書く。

ベータ機能ゆえの将来的な仕様変更。 公式ドキュメント冒頭に明記されている通り、Permission Profilesは「active development」中であり、本記事の記述は2026年8月27日時点のもの。

具体的な設定例の網羅。 公式ドキュメントには「Common profiles」として複数の設定例（読み取り専用＋ネットワーク許可リスト等）が載っているが、本記事では代表的な仕組みの説明にとどめ、TOML設定例の全パターンは転記していない。

エンタープライズのロールアウト手順の全体像。 allowed_sandbox_modesを暫定の互換制約として残せる仕組みと、その解除条件（Codex 0.138.0以降への統一）までは確認できたが、実際の展開作業（管理コンソールでの設定手順そのもの）は本記事では扱っていない。

Codex cloudとローカルPermission Profilesの設定の連動有無。 両者とも「既定は閉じる」という設計思想は共通していると確認できたが、片方の設定がもう片方に影響するかどうか（連動の有無）までは、今回参照した範囲の公式ドキュメントでは明記されておらず確認できなかった。

関連記事

• Codex Auto-reviewの仕組み──サンドボックス境界越えの承認を別レビュアーに任せる
• CodexのGoal Modeが実験段階を終えた
• AGENTS.md vs CLAUDE.md──優先順位はどう決まるか