権限¶

ベータ版です。権限プロファイルは現在も活発に開発されており、変更される可能性があります。

権限プロファイルは、以前のサンドボックス設定とは組み合わせて使用できません。 default_permissions と [permissions]、または sandbox_mode / sandbox_workspace_write のいずれか一方だけを設定してください。読み込まれた設定ファイルのいずれかに sandbox_mode が含まれている場合、--sandbox を渡した場合、または選択した設定プロファイルで sandbox_mode が設定されている場合、Codex は default_permissions の代わりに以前のサンドボックス設定を使用します。

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

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

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

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

Codex のクラウドネットワーク設定については、インターネットアクセスを参照してください。

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

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 は未知の親と継承サイクルも拒否します。

設定仕様¶

エントリ	型 / 値	デフォルト	詳細
`default_permissions`	文字列のプロファイル名	なし	Codex がデフォルトで適用する権限プロファイルの名前です。`[permissions]` 内のプロファイル、または `:workspace` などの組み込みプロファイルと一致する必要があります。予測可能な動作のため、明示的に設定してください。管理対象の要件では、`:workspace` と `:read-only` の両方が明示的に許可されている場合に限り、この値を省略できます。この設定で管理対象の `allowed_permission_profiles` が権限プロファイルを使用するよう指示していない場合、Codex は以前のサンドボックス設定を使用します。
`[permissions.<name>]`	テーブル	なし	名前付きプロファイルを定義します。`default_permissions` は、1 つのプロファイルをデフォルトとして選択します。その他の権限プロファイル設定でもプロファイル名を使用します。
`permissions.<name>.description`	文字列	なし	プロファイルの人間が読める説明を指定します。`extends` を使用しても、プロファイルは親の説明を継承しません。
`permissions.<name>.extends`	文字列のプロファイル名	なし	このプロファイルを別の名前付きプロファイル、または組み込みの `:read-only` / `:workspace` プロファイルから開始します。Codex は `:danger-full-access`、未知の親、継承サイクルを拒否します。
`[permissions.<name>.workspace_roots]`	テーブル	なし	現在のセッションのランタイムワークスペースルートとともに、`:workspace_roots` ファイルシステムルールを受け取る、プロファイルに定義されたワークスペースルートを追加します。
`permissions.<name>.workspace_roots."<path>"`	ブール値	`false`	`true` の場合、そのパスをプロファイルのワークスペースルート集合に追加します。`false` に設定されたエントリは無効なままです。
`[permissions.<name>.filesystem]`	テーブル	なし	ファイルシステムパスをアクセス値またはスコープ付きサブパスマップにマッピングします。ファイルシステムテーブルがないか空の場合、ファイルシステムアクセスは制限されたままとなり、起動時に警告が出力されます。
`permissions.<name>.filesystem.glob_scan_max_depth`	数値	なし	Codex がサンドボックスの起動前に一致をスナップショットする際、Linux、WSL、ネイティブ Windows で deny-read glob の展開を制限します。値を大きくすると、起動時のスキャン処理が増える可能性があります。上限のない `**` パターンに上限付きの事前展開が必要な場合は、少なくとも `1` の値を使用してください。
`[permissions.<name>.filesystem]."<path>"`	`read`、`write`、または `deny`	なし	サポート対象のパスへの直接アクセスを許可します。`deny` はアクセスを拒否し、同じ具体性の `write` または `read` エントリより優先されます。Codex は、アクティブなランタイムが適用できない直接書き込みルールを拒否します。
`[permissions.<name>.filesystem."<path>"]."<subpath>"`	`read`、`write`、または `deny`	なし	`<path>` の子孫へのアクセスを許可します。ベースパスには `.` を使用してください。その他のサブパスは相対的な子孫である必要があり、`.` または `..` コンポーネントを含めることはできません。
`[permissions.<name>.network]`	テーブル	なし	プロファイルのネットワークサンドボックスプロキシとサンドボックスネットワークポリシーを設定します。
`permissions.<name>.network.enabled`	ブール値	`false`	プロファイル内のサンドボックス化されたコマンドに対するネットワークアクセスを有効にします。これはサンドボックスのネットワークポリシーを変更しますが、ネットワークプロキシ自体を起動するものではありません。
`[permissions.<name>.network.domains]`	テーブル	なし	ホストパターンを `allow` または `deny` にマッピングします。`allow` エントリがない場合、ドメインリクエストはブロックされます。拒否エントリは許可エントリより優先されます。
`permissions.<name>.network.domains."<pattern>"`	`allow` または `deny`	なし	完全一致ホスト、サブドメイン用の `.example.com`、頂点ドメインとサブドメイン用の `.example.com`、および許可専用のグローバルワイルドカードとしての `` をサポートします。ホストパターンは、前後の空白の削除、小文字化、末尾のドットの削除、単純なポートまたは角括弧の削除によって正規化されます。
`[permissions.<name>.network.unix_sockets]`	テーブル	なし	Unix ソケットの許可リスト上書きをマッピングします。Docker などのローカル統合にのみ使用してください。
`permissions.<name>.network.unix_sockets."<path>"`	`allow` または `deny`	なし	`allow` によって絶対 Unix ソケットパスを有効な許可リストに追加するか、`deny` によって拒否します。拒否されたエントリは有効な許可リストから除外されます。
`permissions.<name>.network.proxy_url`	URL 文字列	`http://127.0.0.1:3128`	`HTTP_PROXY`、`HTTPS_PROXY`、WebSocket プロキシ変数、および関連するツールのプロキシ環境変数に使用される HTTP プロキシリスナーです。
`permissions.<name>.network.enable_socks5`	ブール値	`true`	`ALL_PROXY` と FTP プロキシ変数に使用される SOCKS5 リスナーを有効にします。
`permissions.<name>.network.socks_url`	URL 文字列	`http://127.0.0.1:8081`	SOCKS5 リスナーのアドレスです。
`permissions.<name>.network.enable_socks5_udp`	ブール値	`true`	SOCKS5 リスナーが有効な場合に SOCKS5 UDP サポートを有効にします。
`permissions.<name>.network.allow_upstream_proxy`	ブール値	`true`	ネットワークサンドボックスプロキシが、送信リクエストに対する上流の `HTTP(S)_PROXY` および `ALL_PROXY` 設定を尊重することを許可します。
`permissions.<name>.network.allow_local_binding`	ブール値	`false`	`true` の場合にローカル / プライベートネットワークガードを無効にします。`false` の場合、`localhost` や `127.0.0.1` などの正確なローカルリテラルを明示的に許可リストに追加する必要があり、ローカルまたはプライベート IP に解決されるホスト名は引き続きブロックされます。
`permissions.<name>.network.dangerously_allow_non_loopback_proxy`	ブール値	`false`	プロキシリスナーがループバック以外のアドレスにバインドすることを許可します。通常のローカル開発では未設定のままにしてください。
`permissions.<name>.network.dangerously_allow_all_unix_sockets`	ブール値	`false`	Unix ソケットプロキシがサポートされる環境で、Unix ソケットの許可リストをバイパスします。これは広範なローカル脱出口です。

ファイルシステム権限¶

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

アクセス	意味
`read`	コマンドによるファイルの読み取りと、パス下のディレクトリ一覧の取得を許可します。コマンドは、その場所でファイルを作成、変更、名前変更、削除できません。
`write`	パス下のファイルの読み取りと変更を許可します。OS が許可する場合、ファイルの作成、名前変更、削除も含まれます。
`deny`	パス下での読み取りと書き込みの両方を拒否します。より広範な `read` または `write` の許可から、拒否するサブパスを切り出すために使用します。

より具体的なエントリは、より広いエントリより優先されます。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"

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

パス	意味	スコープ付きサブパス
`:root`	ファイルシステムのルート	`.` のみ
`:minimal`	一般的なツールに必要なプラットフォームおよびランタイムパス	`.` のみ
`:workspace_roots`	現在のセッションのワークスペースルートと、有効化されたプロファイル定義のワークスペースルート	はい
`:tmpdir`	利用可能な場合の `$TMPDIR` の場所	`.` のみ
`:slash_tmp`	存在する場合の `/tmp` フォルダー	`.` のみ
`/absolute/path`	macOS / Linux / WSL の `/path` や、ネイティブ Windows の `C:\path` など、プラットフォームの絶対パス	はい
`~/path`	現在のユーザーのホームディレクトリ下のパス	はい

ネイティブ 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 パターンは deny-read ルールとしてサポートされています。read または write glob は、Linux、WSL、ネイティブ Windows のサンドボックスでは移植性が低いため、可能な場合は "docs/**" = "read" のような正確なパスまたはサブツリールールを使用してください。

Linux、WSL、ネイティブ Windows では、上限のない ** deny-read パターンについて、サンドボックスの起動前に上限付きの事前展開が必要になる場合があります。"**/*.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 サーバー、組み込みブラウザー、コンピュータ操作、Codex クラウド用の個別の制御と組み合わせて使用してください。

プロファイルが制御するもの¶

ローカルコマンドの実行: 権限プロファイルは、マシン上で実行されるサンドボックス化されたコマンドを管理します。コネクター、MCP サーバー、ブラウザーまたはコンピュータ操作のサーフェス、Codex クラウド環境の設定、承認済みのエスカレーションには、それぞれ独自の制御があります。
ファイルシステムへの書き込み: 書き込み可能なプロファイルでは、永続的な変更を作成できます。スクリプト、ビルド手順、パッケージマネージャーのフック、シェルの起動ファイル、共有ディレクトリへの書き込みは機密性の高い操作として扱ってください。後続のツールやユーザーが、元のサンドボックスコンテキストの外でこれらのファイルを実行できるためです。
送信先: ネットワークドメインルールは、サンドボックス化されたコマンドのトラフィックがネットワークプロキシを通じて到達できる場所を制限します。許可された宛先が信頼できるかどうかは判断せず、ワイルドカードの許可ルールは広範なままです。
ローカルサービス: ローカルおよびプライベートネットワークのターゲットは、デフォルトでブロックされます。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

パブリック Web アクセス付きのワークスペース書き込み¶

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"

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