権限

管理対象の 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 には、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 を拡張すると、 明示的にオーバーライドしない限り、ワークスペースルートの .codex ディレクトリは 読み取り専用のままになります。親は一度だけ設定し、異なるルールだけを追加または オーバーライドしてください。

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 ファイルの読み取りを拒否します。通常のワークスペースへの書き込みを 維持しながら、環境ファイル、生成されたシークレット、または同様に認証情報を含むファイルを 読み取り不可にする場合に使用してください。

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 を使用します。

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

適用範囲と強制

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

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

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

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

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

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

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

強制の仕組み

• macOS では、Codex は Seatbelt サンドボックスプロファイルを使用します。選択したポリシーを プラットフォームのサンドボックスで強制できない場合、サンドボックスなしで暗黙に実行するのではなく、 Codex はコマンドの実行を拒否します。
• Linux と WSL では、Codex は bubblewrap および seccompを使用し、 互換性フォールバックパスでは Landlock も利用できます。最も強力な強制パスは、ユーザー名前空間と カーネルのサポートによって異なります。制限されたコンテナホストでは互換性パスが強制されることがあり、 サポートされていない分割ポリシーは拒否されます。
• ネイティブ Windows では、専用の低権限サンドボックスユーザー、ファイルシステム権限の境界、 ファイアウォールルールを使用できるため、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
# subfolders such as .codex/ and .git/ 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"

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