権限

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

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

ローカル権限プロファイルは macOS、Linux、WSL、ネイティブ Windows で利用できます。プラットフォームごとの詳細と注意点は「適用範囲と制限の仕組み」を参照してください。

現行の Codex Cloud のネットワーク設定については「サービスへの接続」を、Codex Cloud（レガシー）については「インターネットアクセス」を参照してください。

プロファイルの定義と選択

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 パターンが適しています。

:workspace_roots の下に指定した glob は、有効な各ワークスペースルートを基準に解釈されます。たとえば、次のように指定します。

[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 では、深さに制限のない ** の読み取り拒否パターンを、サンドボックスの起動前に一定の深さまで展開する必要がある場合があります。glob_scan_max_depth は、"**/*.env" = "deny" のように深さに制限のないパターンを使用するときに設定してください。

[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

動作は 2 つの設定の組み合わせによって決まります。

• ネットワークが無効な場合、プロキシ機能の設定にかかわらず、コマンドはネットワークにアクセスできません。
• ネットワークが有効でプロキシが無効な場合、コマンドは制限なくネットワークに直接アクセスできます。権限プロファイルのドメインルールは適用されません。
• ネットワークとプロキシがどちらも有効な場合、コマンドはプロキシを使用し、プロファイルのドメインルールが適用されます。稼働中のプロキシに許可ドメインが設定されていなければ、外部への接続はブロックされます。

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

ネットワークサンドボックスのプロキシは、デフォルトでは次のローカルアドレスで接続を待ち受けます。

[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 の組み合わせを権限プロファイルに置き換えます。各セッションでは、どちらか一方の方式だけを使用してください。

用途別に、次の設定から始めることを推奨します。

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

プロファイルは、セッションのローカルアクセス権のデフォルトを定義します。組織が管理する要件でさらに制限を設けることができ、ユーザー設定でその制限を緩めるべきではありません。管理者が適用するファイルシステムとネットワークの制限については「管理設定」を参照してください。

適用範囲と制限の仕組み

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

Work Cloud からローカルコンピューターにアクセスする各環境のポリシーを確認してください。

• 企業の管理要件： ローカルアクセスを利用する Work と dot では、管理ポリシーが有効な場合、サポートされているグローバルポリシーが共有クラウドオーケストレーターに適用されます。接続先のコンピューターには、該当するローカル実行要件が適用されます。
• クラウドでの実行： Work のクラウドコンテナには、既存の Work Cloud ポリシーが適用されます。
• ローカルポリシーの優先順位： MDM と従来の管理対象デバイスの要件は、Agent Security よりも優先されます。デバイスのシステム要件ファイルの優先順位は、Agent Security よりも低くなります。
• ポリシーの優先順位： 優先順位の低いポリシーのほうが対象を細かく指定していても、優先順位の高いポリシーが適用されます。同一ポリシー内では、OS 別の環境設定による上書き、全 OS 共通の環境設定による上書き、グローバル設定の順に優先されます。

要件によっては、フィールドごとに異なるマージルールがあります。サポートされるフィールドと実行時の制限については、「管理設定」と「設定リファレンス」を参照してください。ここで紹介する Codex の権限プロファイルを Work Cloud でも使用できるとは限りません。

権限プロファイルは、ローカルのサンドボックス内で実行するコマンドのアクセス範囲を定めます。承認ポリシーや、ウェブ検索、コネクタ、MCP サーバー、組み込みブラウザ、コンピューターの使用、Codex Cloud それぞれの制御設定と併用してください。

プロファイルの制御対象

• ローカルコマンドの実行： 権限プロファイルは、マシン上のサンドボックス内で実行されるコマンドに適用されます。コネクタ、MCP サーバー、ブラウザやコンピューターの使用、Codex Cloud の環境設定、承認済みの権限昇格には、それぞれ独自の制御が適用されます。
• ファイルシステムへの書き込み： 書き込みを許可するプロファイルでは、実行後も変更が残ることがあります。スクリプト、ビルド手順、パッケージマネージャーのフック、シェルの起動ファイル、共有ディレクトリへの書き込みは慎重に扱ってください。後で別のツールやユーザーが、元のサンドボックスの外でこれらのファイルを実行できるためです。
• 外部への接続先： ネットワークのドメインルールでサンドボックス内のコマンドの通信先を制限できるのは、ネットワークプロキシが動作している間だけです。許可した宛先の信頼性までは判定されません。ワイルドカードを使った許可ルールの対象範囲は広いままです。
• ローカルサービス： 稼働中のネットワークプロキシは、デフォルトでローカルネットワークとプライベートネットワークへの接続をブロックします。localhost、プライベート IP アドレス、Unix ソケットを許可リストに追加するか、allow_local_binding = true を設定すると、ローカルサービスへのアクセスを明示的に開放することになります。

ネットワークプロキシの制御対象外

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

• ウェブ検索： ホスト型の検索ツールは独自のアクセス設定を使用します。web_search で制御し、管理対象クライアントでは allowed_web_search_modes も使用します。tools.web_search.allowed_domains は検索結果を絞り込む設定で、コマンドのネットワークアクセスには適用されません。
• アプリとコネクタ： コネクタを利用するツールは、サービス側の接続、ワークスペースの権限、アプリやツールの設定を使用します。
• MCP サーバー： ローカルおよびリモートの MCP サーバーは、独自のプロセスまたはトランスポートを使用します。mcp_servers の設定と、管理者が設定するサーバーの許可リストで制御してください。
• ブラウザとコンピューターの使用： ブラウザでの移動やコンピューターの操作には、それぞれの機能設定と承認設定が適用されます。
• Codex サービスとの通信： モデル、認証、その他のクライアントサービスへのリクエストには、クライアント側で別途設定された HTTP とシステムプロキシの設定が適用されます。
• Codex Cloud： タスクは、実行環境固有のネットワーク設定を使用します。Codex Cloud（レガシー）には専用のインターネットアクセス設定があります。

これらの機能を制限するには、機能ごとに直接設定してください。コマンド用のネットワーク許可リストは、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"

すべてのホストを対象とする "*" の許可ルールは、公開ネットワークへのアクセスを意図的に許可する場合にのみ使用してください。拒否ルールを追加すると、広い許可リストの対象を絞り込めます。