OpenAI Codexのエンジニアリングリードを務めるThibault Sottiaux氏は2026年6月29日、コーディングエージェントCodex向けの「Permission profiles」を案内した。この機能は、Permissionsのドキュメントページでベータとされている。Codexの設定ファイルに[permissions.]として権限セットを定義し、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の読み取り拒否や接続先ドメインの許可・拒否までを、名前付きの再利用可能なプロファイルとしてまとめることはできなかった。
[1] 同じ権限選択で選べる「Ask for approval」「Approve for me」「Full access」は、Permission profilesそのものではなく、サンドボックス境界、承認ポリシー、承認レビューの扱いを組み合わせた製品側の権限モードにあたる。Sandboxingページでは、Full accessを、サンドボックス制限を外すdanger-full-accessと、承認プロンプトを出さないneverの組み合わせとしている。サンドボックス内では作業を進め、境界を越える操作だけ承認対象にしたい場合は、workspace-writeとon-requestの組み合わせが例になる。この場合、承認の確認先はユーザーまたは自動レビューにできる。
Permission profilesでは、同じconfig.toml上で、ローカルでサンドボックス化されたコマンド実行の権限境界を、より細かな名前付きプロファイルとして記述する[2]。ユーザー設定の~/.codex/config.tomlや、信頼済みプロジェクト内の.codex/config.tomlに[permissions.]としてファイルシステムとネットワークの権限セットを定義し、その名前をdefault_permissionsに指定すると、Codexが既定の権限プロファイルとして使う。Permission profilesを使う設定では、これまでのsandbox_modeやsandbox_workspace_writeを同時に使うことは想定されていない。
設定後は、プロンプト入力欄の権限選択にプロファイル名が表示され、そこから選べるようになる。
[2] 2026年5月28日のCodex CLI 0.135.0では、CLI上の権限選択に使う/permissionsコマンドが、名前付きPermission profilesと設定済みカスタムプロファイルの表示に対応している。
なお、OpenAIによると、App connectors、MCPサーバー、ブラウザーやコンピューター操作、Codexクラウド環境、承認を経た権限昇格は、Permission profilesではなく、それぞれ別の仕組みで制御される。サンドボックスや承認設定の概要は、Sandboxingのドキュメントで確認できる。
Permission profilesで指定できる組み込みプロファイルには、ローカルコマンド実行を読み取り専用にする:read-only、アクティブなワークスペースルートと一時ディレクトリへの書き込みを許可する:workspace、ローカルサンドボックス制限を外す:danger-full-accessが用意される。ユーザーや管理者は、[permissions.]で独自のプロファイルを定義し、ワークスペースルート、ファイルアクセス、ネットワークアクセスを用途に応じて組み合わせられる。
ファイルアクセスでは、[permissions..filesystem]に対象パスや特別なスコープを書き、値としてread、write、denyを指定する。特別なスコープのうち:minimalは、ファイルシステム全体ではなく、シェルから一般的なコマンドを実行するために必要な最小限のシステム領域やランタイム関連パスを対象にする。ファイルシステム全体を対象にする場合は:rootを使う。ほかにも、各ワークスペースルートを表す:workspace_roots、環境変数$TMPDIRが指す一時ディレクトリを表す:tmpdir、/tmpそのものを表す:slash_tmp、絶対パス、~/path形式のホーム配下パスを指定できる。
ワークスペース内の特定のパスに絞ってルールを置く場合は、[permissions..filesystem.”:workspace_roots”]のように、スコープ配下のテーブルを使う。より具体的なルールが広いルールを上書きし、同じパスを対象にする場合はdenyが優先される。たとえばワークスペース全体を書き込み可能にしつつ、**/*.envのようなグロブで環境ファイルの読み取りを拒否できる。ネイティブWindowsではドライブレター付きパスやUNCパスも絶対パスとして扱える。
ネットワーク権限では、[permissions..network]でプロファイルごとのネットワーク利用を有効にし、[permissions..network.domains]で接続先ホストやドメインごとのallowとdenyを指定する[3]。個別ホストはapi.openai.comのように書き、*.example.comはサブドメインのみ、**.example.comはexample.com自体とサブドメインの両方を対象にする。拒否ルールは許可ルールより優先される。
ローカルサービスへのアクセスはデフォルトで保護されるため、ローカルの開発サーバーに接続する場合は、localhostや127.0.0.1を明示的に許可する。ドメインルールにポート番号を書く必要はない。Dockerなどのローカル連携向けにはUnixソケットの許可リストも用意されている。
[3] ここでいうネットワーク権限は、Codexがローカルで実行するコマンドやサブプロセスの通信を対象にする。Web検索ツールの設定（たとえばweb_search = “cached”）とは別に扱う。
次の例では、承認ポリシーやWeb検索設定をトップレベルに置く。そのうえで、ワークスペース内の編集を許可しつつ、.envファイルの読み取りを拒否し、スキル作成などに使うホームディレクトリ配下の.agentsには書き込めるようにする。ネットワークについては、ローカルで実行するコマンドの接続先をapi.openai.comに絞っている。
approval_policy = “on-request”
web_search = “cached”
default_permissions = “project-edit”
[permissions.project-edit.filesystem]
“:minimal” = “read”
“~/.agents” = “write”
[permissions.project-edit.filesystem.”:workspace_roots”]
“.” = “write”
“**/*.env” = “deny”
[permissions.project-edit.network]
enabled = true
[permissions.project-edit.network.domains]
“api.openai.com” = “allow”
企業向けの管理では、管理者がrequirements.toml互換の要件設定でallowed_permission_profilesを指定し、ユーザーが選べる組み込みプロファイルやカスタムプロファイルを制限できる。管理者は同じ要件設定内でカスタムプロファイルを定義し、default_permissionsで既定値として指定することもできる。このテーブルは完全な許可リストとして扱われ、trueに設定されていないプロファイルや省略されたプロファイルは、将来追加される組み込みプロファイルも含めて拒否される[4]。
[4] この許可リストの利用にはCodex CLI 0.138.0以降が必要で、Codex CLI 0.137.0以前ではallowed_permission_profilesとマネージドなdefault_permissionsが無視される。
書き込み先や外部通信先を細かく指定できる一方で、許可範囲を広げすぎるとサンドボックスの効果は弱まる。利用時は、作業に必要な範囲に絞ってプロファイルを作り、承認ポリシーや秘密情報の扱いとあわせて確認したい。
コラム：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”
“~/AppData/Roaming/npm” = “read”
“~/AppData/Local/Programs/Python” = “read”
“~/AppData/Roaming/Python” = “read”
“~/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にする。