権限

管理対象の allowed_permission_profiles は例外であり、Codex に権限プロファイルを使用させます。管理対象プロファイルの許可リストを展開する前に、 sandbox_mode や [sandbox_workspace_write] などの従来の設定を削除してください。複数バージョンが混在するエンタープライズ展開では、すべてのクライアントが Codex 0.138.0 以降を実行するようになるまで、管理対象の allowed_sandbox_modes 要件を一時的な互換性制約として維持できます。

権限プロファイルを使用すると、Codex がユーザーに代わって実行するローカルコマンドに最小権限の境界を適用できます。プロファイルとは、コマンドが読み書きできる範囲を定義するファイルシステムルールと、コマンドが到達できる宛先を定義するネットワークルールを組み合わせた名前付きポリシーです。

プロファイルを使用すると、マシンやネットワークへの広範なアクセスを許可せずに、現在のチャットに必要なアクセス権だけを Codex に付与できます。たとえば、読み取り専用プロファイルでは、 Codex がプロジェクトを編集せずに調査できるようにし、書き込み可能なプロファイルでは、編集範囲を選択したワークスペースルートに限定できます。

ローカル権限プロファイルは、macOS、Linux、WSL、ネイティブ Windows でサポートされています。プラットフォーム固有の詳細と注意事項については、 適用範囲と強制を参照してください。

現在の Codex Cloud のネットワーク設定については、サービスへの接続を参照してください。Codex Cloud (Legacy) については、インターネットアクセスを参照してください。

プロファイルを定義して選択する

Codex には、3 つの組み込み権限プロファイルがあります。

• :read-only は、ローカルコマンドの実行を読み取り専用に保ちます。
• :workspace は、アクティブなワークスペースルートとシステムの一時ディレクトリ内への書き込みを許可します。
• :danger-full-access はローカルサンドボックスの制限を解除するため、そのような広範なアクセスを意図している場合にのみ使用してください。

[permissions.<name>] の下に名前付きプロファイルを作成し、トップレベルの default_permissions キーをそのプロファイル名、または上記の組み込みプロファイルのいずれかに設定します。この例の project-edit はユーザー定義のプロファイル名であり、組み込みの値ではありません。

エンタープライズ管理者は、管理対象の requirements.toml を使用してプロファイルを定義し、ユーザーが選択できるプロファイルを制限できます。allowed_permission_profiles が存在すると、省略されたプロファイルは拒否されます。これには、省略された組み込みプロファイルや、 Codex の将来のバージョンで追加されるプロファイルも含まれます。推奨される管理対象設定については、 利用可能な権限プロファイルを制御するを参照してください。

カスタムプロファイルでは、関連する次の 2 つの概念を使用します。

• [permissions.<name>.workspace_roots] は、そのプロファイルでワークスペースルートとして扱う具体的なディレクトリを追加します。
• [permissions.<name>.filesystem.":workspace_roots"] は、有効なすべてのワークスペースルート、つまり現在のセッションのランタイムワークスペースルートと、上記のプロファイル定義ルート内で Codex が適用するファイルシステムルールを定義します。

プロファイルでも通常の設定レイヤーモデルを使用します。優先順位の高いレイヤーは、プロファイル全体を再記述せずに、同じプロファイル名の配下にエントリを追加または置換できます。

たとえば、組織レベルの設定とユーザーレベルの設定で、同じプロファイルを個別に拡張できます。

# /etc/codex/config.toml
[permissions.server.workspace_roots]
"~/code/server" = true

# ~/.codex/config.toml
[permissions.server.workspace_roots]
"~/code/mobile-app" = true

server がアクティブな場合、両方のワークスペースルートが有効なプロファイルに含まれます。

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit.workspace_roots]
"~/code/app" = true
"~/code/shared-lib" = true

[permissions.project-edit.filesystem]
":minimal" = "read"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
".devcontainer" = "read"
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"
"objects.githubusercontent.com" = "allow"
"*.github.com" = "allow"
"tracking.example.com" = "deny"

このプロファイルは、次のように動作します。

• 一般的な開発ツールに必要な最小限のランタイムパスを読み取ります。
• 現在のセッションとプロファイル定義ルートに、同じワークスペースルートルールを適用します。
• 各ルート配下で、.devcontainer/ などの IDE 関連設定を読み取り専用に保ちます。
• 一致する環境ファイルを glob ルールで拒否します。
• 設定済みのドメインポリシーを介したネットワークアクセスのみを許可します。

アクティブなプロファイル内では、より広いパスが読み取り可能または書き込み可能な場合でも、範囲の狭い拒否ルールは引き続き適用されます。たとえば、ワークスペースルートを書き込み可能にしながら、一致する .env パスを deny に設定できます。

プロファイルを拡張する

プロファイルが組み込みプロファイルや別の名前付きプロファイルとほぼ同じ場合は、extends を 使用します。基本的な保護を引き継げるように、ゼロから作成するよりも 組み込みプロファイルの拡張を推奨します。たとえば、:workspace を拡張すると、 ワークスペースルートの .git、.agents、.codex、.aws の各パスは読み取り専用に保たれます。 これは、ルールを明示的に上書きしない限り変わりません。親を一度設定したら、 異なるルールだけを追加または上書きします。

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit]
description = "Project editing with OpenAI API access."
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

このプロファイルは :workspace を基に開始し、一致する .env ファイルを拒否したまま、 api.openai.com へのリクエストを許可します。プロファイルは :read-only、 :workspace、または別の名前付きプロファイルを拡張できます。 :danger-full-access は拡張できません。また、Codex は不明な親や継承の循環も拒否します。

設定仕様

ファイルシステム権限

ファイルシステムエントリでは、read、write、または deny を使用します。

より具体的なエントリは、より広範なエントリをオーバーライドします。2 つのエントリが同じパスを対象とする場合、deny は write より優先され、write は read より優先されます。

この優先順位により、プロファイルでは最初に広範な作業領域を記述し、その後で読み取り不可のままにするファイルやディレクトリを切り出せます。

[permissions.project-edit.filesystem]
":minimal" = "read"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
".devcontainer" = "read"
"**/*.env" = "deny"

この例では、ワークスペースルートは書き込み可能なまま、.devcontainer/ は書き込み可能にはならず読み取り可能なままで、一致する環境ファイルはサンドボックス化されたコマンドから引き続き利用できません。

より具体的なパスによって、広範な拒否の内側にある範囲の狭いサブツリーを再び開くこともできます。

[permissions.project-edit.filesystem]
"~/Documents" = "deny"
"~/Documents/codex" = "write"

サポートされるパス形式は次のとおりです。

ネイティブ Windows では、ホーム相対パスに ~\work のようなバックスラッシュも使用できます。

プロファイルで広範な読み取り範囲が意図的に必要な場合にのみ、:root を使用してください。

[permissions.audit.filesystem]
":root" = "read"

:workspace_roots の下にネストしたエントリを使用して、アクセスをワークスペースルートからの相対サブパスに限定します。

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"          # each workspace root
"docs" = "read"        # each workspace-root docs directory
"generated" = "deny"   # each workspace-root generated directory

ネストしたサブパスは、そのワークスペースルート内に収まる必要があります。 ../other-repo のような親への移動は拒否されます。

完全一致パスまたは glob で読み取りを拒否する

近接するより広範なプロファイルルールでアクセスが許可されていても Codex に読み取らせないファイルやサブツリーには、deny を使用します。完全一致パスは、~/.ssh のような場所が変わらない場合に適しています。glob パターンは、リポジトリごとに正確な場所が異なる一連の機密ファイルをプロファイルで対象にする場合に適しています。

glob が :workspace_roots の下にある場合、Codex はそれぞれの有効なワークスペースルートを基準に解釈します。次に例を示します。

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

このルールは、ランタイムまたはプロファイル定義の各ワークスペースルートの配下で見つかった、一致する .env ファイルの読み取りを拒否します。通常のワークスペースへの書き込みを維持しながら、環境ファイル、生成されたシークレット、または同様に認証情報を含むファイルを読み取り不可にする場合に使用してください。

Linux、WSL、および MXC または elevated を使用するネイティブ Windows では、読み取り拒否の glob に一致するファイルがサンドボックス内の各プロセスの起動時に列挙されます。その後に作成された一致ファイルは、そのプロセスの拒否リストには追加されず、ほかの権限でアクセスが許可されていれば読み取れます。たとえば、長時間実行されるシェル、スクリプト、ウォッチャー、開発サーバーは、起動後に作成された、一致する .env ファイルを読み取れます。

このスナップショットは、Codex のセッション全体ではなく、サンドボックス内のプロセスが終了するまで有効です。Codex を通じてサンドボックス内で新しいプロセスを起動すると、一致するファイルが再度列挙されます。すでに実行中のプロセスを使い続けても、その拒否リストは更新されません。実行中のプロセスで新しく作成されたファイルをブロックするために、glob に頼らないでください。 Windows 固有の制限については、Windows MXC の互換性を参照してください。

deny glob パターンは読み取り拒否ルールとしてサポートされています。read または write の glob は、 Linux、WSL、ネイティブ Windows のサンドボックスでは移植性が低いため、可能であれば完全一致パス、または "docs/**" = "read" のようなサブツリールールを使用してください。

Linux、WSL、ネイティブ Windows では、無制限の ** 読み取り拒否パターンに、サンドボックス起動前の上限付き事前展開が必要になることがあります。"**/*.env" = "deny" のような無制限パターンを使用する場合は、glob_scan_max_depth を設定してください。

[permissions.project-edit.filesystem]
glob_scan_max_depth = 3

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

glob_scan_max_depth は少なくとも 1 にする必要があります。値を大きくすると、サンドボックスの起動前により深い階層までスキャンするため、Linux、WSL、ネイティブ Windows で起動時の処理が増えることがあります。上限付きの展開を使用したくない場合は、深さを明示したパターンを列挙してください。たとえば、 *.env、*/*.env、*/*/*.env などです。

現在のセッションルート以外にも同じルールを適用する場合は、再利用可能なワークスペースルートをプロファイルに追加します。

[permissions.project-edit.workspace_roots]
"~/code/app" = true
"~/code/shared-lib" = true

このプロファイルがアクティブな場合、Codex は現在のセッションのランタイムワークスペースルートと、有効なプロファイル定義の各ワークスペースルートに :workspace_roots ルールを適用します。

ネイティブ Windows では、D:\work のようなドライブ文字パスと、 \\server\share のような UNC パスが絶対パスとしてサポートされています。

ネットワーク権限

ネットワークアクセスとネットワークフィルタリングは別々の設定です。コマンドによるネットワークアクセスを許可するには permissions.<name>.network.enabled = true を設定し、プロファイルのドメインルールを適用するには features.network_proxy を有効にします。

[features]
network_proxy = true

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"example.com" = "allow"      # exact host
"*.example.com" = "allow"    # subdomains only
"**.example.com" = "allow"   # apex and subdomains
"ads.example.com" = "deny"   # deny wins over allow

結果として得られる動作は、両方の設定によって異なります。

• ネットワークがオフ：プロキシ機能にかかわらず、コマンドはネットワークにアクセスできません。
• ネットワークがオン、プロキシがオフ：コマンドは制限なくネットワークへ直接アクセスできます。権限プロファイルのドメインルールは適用されません。
• ネットワークがオン、プロキシがオン：コマンドは、プロファイルのドメインルールを適用するプロキシを使用します。アクティブなプロキシに許可されたドメインがない場合、外部の宛先をブロックします。

[permissions.<name>.network.domains] を追加したり、 permissions.<name>.network.enabled = true を設定したりしても、 features.network_proxy は有効になりません。別の方法として、管理者は requirements.toml の [experimental_network] でプロキシを有効にできます。 管理対象設定を参照してください。

アクティブな場合、ネットワークサンドボックスプロキシはデフォルトでローカルリスナーにバインドします。

[permissions.project-edit.network]
enabled = true
proxy_url = "http://127.0.0.1:3128"
enable_socks5 = true
socks_url = "http://127.0.0.1:8081"
enable_socks5_udp = true

特定のランタイムと統合する場合を除き、これらのリスナー設定はデフォルトのままにしてください。 dangerously_* ネットワークキーは特殊な環境向けのエスケープハッチであり、通常のローカル開発には使用しないでください。

ローカルネットワークとプライベートネットワーク

ネットワークプロキシがアクティブな場合、Codex は DNS リバインディングやローカルサービスへの意図しないアクセスを防ぐため、デフォルトでローカル／プライベートネットワークガードを適用します。ローカルのリテラルターゲットを意図的に許可するには、完全一致するホストまたは IP リテラルを許可リストに追加します。

[permissions.project-edit.network.domains]
"localhost" = "allow"
"127.0.0.1" = "allow"

許可リストに登録された、ローカルまたはプライベートアドレスに解決されるホスト名へプロファイルから到達する必要がある場合にのみ、allow_local_binding = true を設定します。

[permissions.project-edit.network]
enabled = true
allow_local_binding = true

[permissions.project-edit.network.domains]
"localhost" = "allow"

Unix ソケット

Unix ソケットプロキシは、Docker などのツール向けのローカルエスケープハッチです。使用は最小限にしてください。

[permissions.project-edit.network.unix_sockets]
"/var/run/docker.sock" = "allow"
"/tmp/old.sock" = "deny"

継承された許可エントリを含め、ソケットパスを拒否するには deny を使用します。拒否されたソケットパスは有効な許可リストから除外されます。

Unix ソケットが有効な場合は、プロキシリスナーをループバックアドレスにバインドしたままにしてください。

従来のサンドボックス設定から移行する

ファイルシステムとネットワークの両方の動作を 1 つの再利用可能なプロファイルで記述する場合、権限プロファイルは従来の sandbox_mode と sandbox_workspace_write の組み合わせに代わるものです。 1 つのセッションではどちらか一方の仕組みを使用し、両方を併用しないでください。

推奨される開始点は次のとおりです。

• 読み取り専用ワークフローには、組み込みの :read-only プロファイルを使用するか、必要な場所にのみ読み取りアクセスできるカスタムプロファイルを定義します。
• ワークスペースを編集する場合は、組み込みの :workspace プロファイルを使用するか、 :workspace_roots を介して書き込みを行い、ワークフローに必要な追加の一時パスやキャッシュパスだけを追加するカスタムプロファイルを定義します。
• 制限なしのローカル実行には、最も広範なローカルアクセスモデルを意図的に使用する場合にのみ :danger-full-access を使用します。

プロファイルは、セッションのローカルにおけるデフォルトのアクセス姿勢を記述します。組織管理の要件では、ユーザー設定によって緩和できない制限を引き続き追加できます。管理者によって強制されるファイルシステムおよびネットワーク制約については、管理対象設定を参照してください。

適用範囲と強制

Work Cloud によるローカルコンピューターへのアクセスと環境ポリシー

Work Cloud によるローカルコンピューターへのアクセスが実行される各環境のポリシーを確認してください。

• Enterprise の要件: ローカルアクセスを伴う Work と dots では、管理ポリシーが有効な場合、サポートされている Global ポリシーが共有クラウドオーケストレーターを制御します。接続されたコンピューターには、該当するローカル実行要件が適用されます。
• クラウドでの実行: Work のクラウドコンテナーには、既存の Work Cloud ポリシーが適用されます。
• ローカルポリシーの優先順位: MDM と従来の管理対象デバイスの要件は、Agent Security より優先されます。デバイスのシステム要件ファイルは、Agent Security より優先順位が低くなります。
• ポリシーの優先順位: 優先順位が低いポリシーのほうが具体的であっても、優先順位が高いポリシーが優先されます。同じポリシー内では、OS 固有の環境の上書き設定が最優先され、次にすべての OS に共通する環境の上書き設定、最後に Global が適用されます。

一部の要件には、フィールド固有のマージルールがあります。サポートされるフィールドと実行時の制限については、管理対象の設定と設定リファレンスを参照してください。ここに示す Codex の権限プロファイルが Work Cloud でもサポートされるとは限りません。

権限プロファイルは、サンドボックス化されたローカルコマンド実行の境界を定義します。承認ポリシー、および Web 検索、コネクター、MCP server、組み込みブラウザ、Computer Use、 Codex cloud 用の個別の制御と組み合わせて使用してください。

プロファイルが制御する対象

• ローカルコマンド実行： 権限プロファイルは、マシン上で実行されるサンドボックス化されたコマンドを管理します。コネクター、MCP server、ブラウザまたは Computer Use のサーフェス、 Codex cloud の環境設定、承認された権限昇格には、それぞれ独自の制御が適用されます。
• ファイルシステムへの書き込み： 書き込み可能なプロファイルでは、永続的な変更を作成できます。スクリプト、ビルドステップ、パッケージマネージャーのフック、シェル起動ファイル、共有ディレクトリへの書き込みは機密性の高い操作として扱ってください。後でツールやユーザーが、元のサンドボックスのコンテキスト外でそれらのファイルを実行する可能性があります。
• 外向きの宛先： ネットワークドメインルールは、ネットワークプロキシがアクティブな間に限り、サンドボックス化されたコマンドの通信先を制限します。許可された宛先が信頼できるかどうかは判断せず、ワイルドカードの許可ルールは広範なままです。
• ローカルサービス： アクティブなネットワークプロキシは、デフォルトでローカルネットワークとプライベートネットワークのターゲットをブロックします。localhost、プライベート IP、Unix ソケットを許可リストに追加するか、allow_local_binding = true を設定すると、ローカルサービスへのアクセスが明示的に開放されます。

ネットワークプロキシが制御しない対象

ネットワークプロキシは、サンドボックス内で実行されるローカルコマンドの通信だけをフィルタリングします。プロファイルのドメイン許可リストは、次の対象には適用されません。

• ウェブ検索: ホスト型の検索ツールは独自のアクセス設定を使用します。 web_search と、管理対象クライアントでは allowed_web_search_modes を使用して制御します。tools.web_search.allowed_domains がフィルタリングするのは検索結果であり、コマンドのネットワークアクセスではありません。
• アプリとコネクター: コネクターを利用するツールは、独自のサービス側の接続、ワークスペース権限、アプリやツールの設定を使用します。
• MCP server: ローカルとリモートの MCP serverは、独自のプロセスまたはトランスポートを使用します。mcp_servers の設定と管理対象サーバーの許可リストで制御してください。
• ブラウザーと Computer Use: ブラウザーのナビゲーションとコンピューター操作は、独自の機能設定と承認制御を使用します。
• Codex サービスの通信: モデル、認証、その他のクライアントサービスへのリクエストは、クライアントの個別の HTTP 設定とシステムプロキシ設定を使用します。
• Codex Cloud: これらのタスクは、環境独自の ネットワーク設定を使用します。 Codex Cloud (Legacy) には個別の インターネットアクセス設定があります。

これらのサーフェスを制限するには、それぞれの機能を直接設定してください。コマンドのネットワーク許可リストは、Codex が実行できるすべての操作を対象としたグローバルなネットワークポリシーではありません。

強制の仕組み

• macOS では、Codex は Seatbelt サンドボックスプロファイルを使用します。選択したポリシーを プラットフォームのサンドボックスで適用できない場合、Codex はコマンドの実行を拒否します。 通知せずにサンドボックス外で実行することはありません。
• Linux と WSL では、Codex は bubblewrap と seccomp を使用して、 ファイルシステムの制限を適用します。従来の Landlock オプションは app-server の Unix ソケットを分離できないため、 ファイルシステムを制限するポリシーでは拒否されます。 アップグレード時には features.use_legacy_landlock を無効にしてください。必要な bubblewrap の操作を ブロックするホストでは、これらのポリシーを実行できません。
• Windows では、MXC はプロセス分離を使用してファイルシステムとネットワークの権限を適用します。 有効にする前に、MXC の互換性を 確認してください。従来の elevated フォールバックは、権限を抑えた専用の サンドボックスユーザー、ファイルシステムの権限境界、ファイアウォールルールを使用します。 unelevated はネットワーク分離が弱い従来のフォールバックで、読み取りと書き込みを分けた 例外設定をすべて適用することはできないため、未対応のポリシーは拒否されます。 Linux のサンドボックスモデルが必要な場合は、WSL を使用してください。

運用ガイダンス

特に書き込みや外向きネットワークアクセスを許可する場合は、タスクを完了できる範囲で最も権限の狭いプロファイルを選択してください。承認ポリシー、シークレットの取り扱い、許可ルールを、そのアクセスレベルに合わせてください。

一般的なプロファイル

ネットワーク許可リスト付きの読み取り専用

default_permissions = "readonly-net"

[features]
network_proxy = true

[permissions.readonly-net.filesystem]
":minimal" = "read"

[permissions.readonly-net.filesystem.":workspace_roots"]
"." = "read"

[permissions.readonly-net.network]
enabled = true

[permissions.readonly-net.network.domains]
"api.openai.com" = "allow"

ファイルアクセスをワークスペースに限定する

次は、ファイルシステムのその他の部分への読み取りを拒否しながら、ワークスペースフォルダーを Codex が書き込み可能にする権限プロファイルの例です（:minimal によって定められる限定的な例外を除きます）。

default_permissions = "workspace-only"

[permissions.workspace-only]
# By extending the :workspace profile, you get Codex's safeguards to ensure
# paths such as .git/, .agents/, .codex/, and .aws/ within a workspace root
# are read-only while the rest of the folder is writable.
extends = ":workspace"

[permissions.workspace-only.filesystem]
# By default, deny read access to all files on disk.
":root" = "deny"

# Though in practice, a software agent needs to be able to read folders that
# contain common tools, such as `/usr/bin`, to get work done, so grant access
# to a "minimal" set of files and folders, as determined by Codex.
":minimal" = "read"

# By extending the :workspace profile, :tmpdir and :slash_tmp are "write" by
# default, though you can deny access to them altogether, if desired.
":tmpdir" = "deny"
":slash_tmp" = "deny"

ネットワークなしでワークスペースに書き込む

default_permissions = "project-edit"

[permissions.project-edit.filesystem]
":minimal" = "read"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"

[permissions.project-edit.network]
enabled = false

公開 Web アクセス付きでワークスペースに書き込む

default_permissions = "workspace-net"

[features]
network_proxy = true

[permissions.workspace-net.filesystem]
":minimal" = "read"

[permissions.workspace-net.filesystem.":workspace_roots"]
"." = "write"

[permissions.workspace-net.network]
enabled = true

[permissions.workspace-net.network.domains]
"*" = "allow"

公開ネットワークアクセスを許可する意図がある場合にのみ、グローバルな "*" 許可ルールを使用してください。拒否ルールで、広範な許可リストを狭めることができます。