OpenAI、Codexのベータ機能「Permission profiles」を案内 ――config.tomlでファイルアクセスと通信先を制御

OpenAI Codexのエンジニアリングリードを務めるThibault Sottiaux氏は2026年6月29日、コーディングエージェントCodex向けの「Permission profiles」を案内した。この機能は、Permissionsのドキュメントページでベータとされている。Codexの設定ファイルに[permissions.<name>]として権限セットを定義し、default_permissionsで利用するプロファイルを選ぶ仕組みで、ファイルシステムの読み取り、書き込み、拒否のルールと、接続できるネットワーク宛先の制御を1つのプロファイルにまとめられる。

Codexでは、画面上の権限選択やCLIでの設定指定を通じて、config.tomlに書いた権限関連の設定を使える。画面上では「Custom (config.toml)」がこの選択肢にあたる。これまでも、config.tomlでサンドボックスの大枠を選ぶsandbox_mode、承認の求め方を決めるapproval_policy、承認の確認先を指定するapprovals_reviewer、ワークスペース書き込み時の追加設定を扱うsandbox_workspace_writeなどを指定できた[1]。

これまでの設定では、たとえばワークスペース内の書き込みを許可し、必要に応じて追加の書き込み先やネットワーク利用を指定する場合、次のように大まかなサンドボックスモードと追加設定を組み合わせていた。

sandbox_mode = "workspace-write"
approval_policy = "on-request"  # サンドボックス境界を越える操作で承認を求める

[sandbox_workspace_write]
writable_roots = ["~/.agents"]
network_access = false

この方式でもワークスペース外の書き込み先やネットワーク利用の有無は設定できたが、.envの読み取り拒否や接続先ドメインの許可・拒否までを、名前付きの再利用可能なプロファイルとしてまとめることはできなかった。

Permission profilesでは、同じconfig.toml上で、ローカルでサンドボックス化されたコマンド実行の権限境界を、より細かな名前付きプロファイルとして記述する[2]。ユーザー設定の~/.codex/config.tomlや、信頼済みプロジェクト内の.codex/config.tomlに[permissions.<name>]としてファイルシステムとネットワークの権限セットを定義し、その名前をdefault_permissionsに指定すると、Codexが既定の権限プロファイルとして使う。Permission profilesを使う設定では、これまでのsandbox_modeやsandbox_workspace_writeを同時に使うことは想定されていない。

設定後は、プロンプト入力欄の権限選択にプロファイル名が表示され、そこから選べるようになる。

なお、OpenAIによると、App connectors、MCPサーバー、ブラウザーやコンピューター操作、Codexクラウド環境、承認を経た権限昇格は、Permission profilesではなく、それぞれ別の仕組みで制御される。サンドボックスや承認設定の概要は、Sandboxingのドキュメントで確認できる。

Permission profilesで指定できる組み込みプロファイルには、ローカルコマンド実行を読み取り専用にする:read-only、アクティブなワークスペースルートと一時ディレクトリへの書き込みを許可する:workspace、ローカルサンドボックス制限を外す:danger-full-accessが用意される。ユーザーや管理者は、[permissions.<name>]で独自のプロファイルを定義し、ワークスペースルート、ファイルアクセス、ネットワークアクセスを用途に応じて組み合わせられる。

ファイルアクセスでは、[permissions.<name>.filesystem]に対象パスや特別なスコープを書き、値としてread、write、denyを指定する。特別なスコープのうち:minimalは、ファイルシステム全体ではなく、シェルから一般的なコマンドを実行するために必要な最小限のシステム領域やランタイム関連パスを対象にする。ファイルシステム全体を対象にする場合は:rootを使う。ほかにも、各ワークスペースルートを表す:workspace_roots、環境変数$TMPDIRが指す一時ディレクトリを表す:tmpdir、/tmpそのものを表す:slash_tmp、絶対パス、~/path形式のホーム配下パスを指定できる。

ワークスペース内の特定のパスに絞ってルールを置く場合は、[permissions.<name>.filesystem.":workspace_roots"]のように、スコープ配下のテーブルを使う。より具体的なルールが広いルールを上書きし、同じパスを対象にする場合はdenyが優先される。たとえばワークスペース全体を書き込み可能にしつつ、**/*.envのようなグロブで環境ファイルの読み取りを拒否できる。ネイティブWindowsではドライブレター付きパスやUNCパスも絶対パスとして扱える。

ネットワーク権限では、[permissions.<name>.network]でプロファイルごとのネットワーク利用を有効にし、[permissions.<name>.network.domains]で接続先ホストやドメインごとのallowとdenyを指定する[3]。個別ホストはapi.openai.comのように書き、*.example.comはサブドメインのみ、**.example.comはexample.com自体とサブドメインの両方を対象にする。拒否ルールは許可ルールより優先される。

ローカルサービスへのアクセスはデフォルトで保護されるため、ローカルの開発サーバーに接続する場合は、localhostや127.0.0.1を明示的に許可する。ドメインルールにポート番号を書く必要はない。Dockerなどのローカル連携向けにはUnixソケットの許可リストも用意されている。

次の例では、承認ポリシーやWeb検索設定をトップレベルに置く。そのうえで、ワークスペース内の編集を許可しつつ、.envファイルの読み取りを拒否し、スキル作成などに使うホームディレクトリ配下の.agentsには書き込めるようにする。ネットワークについては、ローカルで実行するコマンドの接続先をapi.openai.comに絞っている。

# 承認ポリシーとWeb検索は、Permission profileとは別のトップレベル設定
approval_policy = "on-request"  # 承認プロンプトを出さない場合は "never"
web_search = "cached"  # 常に最新の検索は "live"、無効化は "disabled"

# 既定で使うPermission profileを指定する
default_permissions = "project-edit"

# project-editという名前のファイルアクセス権限を定義する
[permissions.project-edit.filesystem]
":minimal" = "read"
"~/.agents" = "write"

# 各ワークスペースルートでは書き込みを許可し、.envは拒否する
[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
"**/*.env" = "deny"

# ローカルで実行するコマンドのネットワーク利用を有効にする
[permissions.project-edit.network]
enabled = true

# コマンドが接続できるドメインを制限する
# localhostや127.0.0.1を使う場合も明示的に許可する
[permissions.project-edit.network.domains]
"api.openai.com" = "allow"
# "localhost" = "allow"
# "127.0.0.1" = "allow"

企業向けの管理では、管理者がrequirements.toml互換の要件設定でallowed_permission_profilesを指定し、ユーザーが選べる組み込みプロファイルやカスタムプロファイルを制限できる。管理者は同じ要件設定内でカスタムプロファイルを定義し、default_permissionsで既定値として指定することもできる。このテーブルは完全な許可リストとして扱われ、trueに設定されていないプロファイルや省略されたプロファイルは、将来追加される組み込みプロファイルも含めて拒否される[4]。

書き込み先や外部通信先を細かく指定できる一方で、許可範囲を広げすぎるとサンドボックスの効果は弱まる。利用時は、作業に必要な範囲に絞ってプロファイルを作り、承認ポリシーや秘密情報の扱いとあわせて確認したい。

コラム⁠：Windowsネイティブ環境での注意

Config basicページは、Windowsネイティブ実行時のサンドボックス設定として[windows] sandbox = "elevated"を推奨し、unelevatedを管理者権限がない場合やelevated setupが失敗する場合のフォールバックとしている。筆者環境では、ユーザー領域に入れたnpmのグローバルツールやPythonを扱いやすくするため、これまでunelevatedを使っていた。

この状態でPermission profilesの制限付き読み取り設定を使ったところ、ローカルファイルの読み取りがRestricted read-only access requires the elevated Windows sandbox backendというエラーで失敗した。[windows] sandbox = "elevated"に変更してセッションを再起動すると、この読み取りは可能になった。この確認結果は、elevatedがPermission profilesの利用条件であることを示すものではないが、筆者環境のようにWindowsで制限付きのファイルアクセス制御を使う場合には確認しておきたい。

Permission profilesでは、許可したパスだけが読み書き対象になる。そのため、PATHに含まれるコマンドでも、実体ファイルや関連ディレクトリがプロファイルの読み取り許可範囲に入っていないと、コマンド解決や実行に失敗する場合がある。筆者環境では、C:\Program Files\nodejsにあるNode.js本体は:minimalの範囲で使えたが、ユーザー領域に入るnpmのグローバルツールやPython、pipで入れたCLIツールは追加の許可を入れて使えるようにした。

既存プロファイルに追記する例は次のとおり。npm installやnpxの実行でキャッシュに書き込む場合は、npmキャッシュディレクトリもwriteにする。

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

# 既存のnpmグローバルツールを実行する場合
"~/AppData/Roaming/npm" = "read"

# ユーザー領域に入れたPython本体やpipのCLIツールを使う場合
"~/AppData/Local/Programs/Python" = "read"
"~/AppData/Roaming/Python" = "read"

# npmやnpxがキャッシュに書き込む場合
"~/AppData/Local/npm-cache" = "write"

npmやpipでツールを新たにユーザー領域へインストールする操作までCodexに実行させる場合は、該当ディレクトリをreadではなくwriteにする必要がある。たとえばnpm install -gを許可するなら~/AppData/Roaming/npmを、python -m pip install --userを許可するなら~/AppData/Roaming/Pythonをwriteにする。