権限

権限プロファイルを使用すると、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"

[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"

[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 パスが絶対パスとしてサポートされています。

ネットワーク権限

選択したプロファイルでネットワークアクセスを許可するには、enabled = true を設定します。

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

ネットワークアクセスが有効な場合、Codex はデフォルトで完全なネットワーク動作を使用します。ほとんどのプロファイルでは、ドメインルールも定義してください。

[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.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 を使用してください。

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

適用範囲と強制

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

プロファイルによって制御されるもの

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

強制の仕組み

• macOS では、Codex は Seatbelt サンドボックスプロファイルを使用します。選択したポリシーをプラットフォームのサンドボックスで強制できない場合、Codex はサンドボックスなしで暗黙的にコマンドを実行するのではなく、実行を拒否します。
• Linux と WSL では、Codex は bubblewrap と seccomp を使用し、互換性のためのフォールバック経路では Landlock も利用できます。最も強力な強制経路は、ユーザー名前空間とカーネルのサポート状況によって異なります。制限されたコンテナホストでは互換性経路が強制される場合があり、サポートされていない分割ポリシーは拒否されます。
• ネイティブ Windows では、elevated サンドボックス が最も強力です。専用の低権限サンドボックスユーザー、ファイルシステムの権限境界、ファイアウォールルールを使用できるためです。unelevated サンドボックスはネットワーク分離が弱いフォールバックであり、すべての読み取り／書き込みの分割除外を強制できないため、サポートされていないポリシーは拒否されます。Linux のサンドボックスモデルが必要な場合は WSL を使用してください。

運用ガイダンス

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

一般的なプロファイル

ネットワーク許可リスト付きの読み取り専用プロファイル

default_permissions = "readonly-net"

[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

公開ウェブへのアクセスとワークスペースへの書き込みを許可する

default_permissions = "workspace-net"

[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"

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