Permissions

概要

ローカルで実行されるコマンドに最小権限の境界を与える仕組み。permission profile は Beta で、活発に開発中であり変わりうると公式に明記されている。profile は filesystem ルール（何を読み書きできるか）と network ルール（どの宛先に到達できるか）を組み合わせた名前付きポリシー。

このページは 2 つのドキュメントセクション（permission mode の UI 説明と、permission profile の仕様）を扱う。permission profile に関する記述はすべて Beta 扱い。

仕様

permission mode（UI 側の説明）

• permissions は、ChatGPT（desktop app）と Codex（CLI / IDE）がファイル編集・コマンド実行・インターネット利用といったローカルのアクションをどう扱うかを制御する
• ほとんどの作業では Ask for approval から始めることが推奨されている。現在のワークスペース内で作業し、その境界を越える前に一時停止する
• ChatGPT desktop app の初回利用時は、アプリ設定でモードを有効にする必要がある
  • Ask for approval は常に利用できる
  • Approve for me（設定上の名称は Auto-review）と Full access をメニューに出すには、Settings > General の Permissions で有効にする
  • モードを有効にしてもメニューに出るだけで、そのモードが選択されたり既存のチャットが変わったりはしない
• 利用できるモードはローカル設定と組織の requirements に依存する。 許可されていないモードは無効表示になる
• sandbox がアクセスできるファイルとネットワークを定め、approvals が一時停止するか自動レビューに送るかを決める
• 誰がレビューするかを変えても sandbox は広がらない。 例えば Approve for me は Ask for approval と同じワークスペース境界を保ち、境界を越える要求を自動レビューに送るだけ
• CLI では /permissions を使う

permission profile と旧 sandbox 設定の関係（重要）

• permission profile は旧来の sandbox 設定と組み合わせられない。 default_permissions と [permissions] を使うか、sandbox_mode / sandbox_workspace_write を使うかのどちらかで、両方は使えない
• 読み込まれたいずれかの config ファイルに sandbox_mode があるか、--sandbox を渡したか、選択した config profile が sandbox_mode を設定している場合、Codex は default_permissions ではなく旧来の sandbox 設定を使う
• 例外は managed の allowed_permission_profiles。これがあると Codex は permission profile を使う。managed の profile allowlist を配る前に sandbox_mode や [sandbox_workspace_write] などの旧設定を消しておく
• バージョンが混在するエンタープライズ展開では、すべてのクライアントが Codex 0.138.0 以降になるまで、managed の allowed_sandbox_modes requirement を一時的な互換制約として残せる

組み込み profile

• ローカルの permission profile は macOS、Linux、WSL、Windows ネイティブで対応している
• エンタープライズ管理者は managed requirements.toml で profile を定義し、ユーザーが選べる profile を制限できる。allowed_permission_profiles があると、そこに書かれていない profile はすべて拒否される（省略された組み込みや、将来の Codex バージョンで追加される profile も含む）

profile の定義

• [permissions.<name>] で名前付き profile を作り、トップレベルの default_permissions にその名前か組み込み名を設定する
• [permissions.<name>.workspace_roots] は、その profile で workspace root として扱う具体的なディレクトリを足す
• [permissions.<name>.filesystem.":workspace_roots"] は、有効なすべての workspace root（現在のセッションのランタイム workspace root ＋ profile が定義した root）の内側に適用する filesystem ルールを定める
• profile も通常の config レイヤーモデルに従う。優先度の高いレイヤーは、profile 全体を書き直さずに同じ profile 名のエントリを追加・置換できる

extends

• 組み込みまたは他の名前付き profile とほぼ同じ場合に使う。ベースラインの保護を引き継ぐため、ゼロから始めるより組み込みの拡張が推奨されている
• 例えば :workspace を拡張すると、明示的に上書きしない限り workspace root の .codex ディレクトリは read-only のまま
• :read-only、:workspace、他の名前付き profile を拡張できる。:danger-full-access は拡張できない。未知の親と継承の循環も拒否される
• description は extends で親から継承されない

設定項目

filesystem のアクセス値

• より具体的なエントリが広いエントリを上書きする。同じパスを指す 2 つのエントリでは deny > write > read
• 広い deny の中で、より具体的なパスにより狭い部分木を再度開くこともできる
• 有効な profile の内側では、広いパスが読み書き可能でも、より狭い deny ルールは効き続ける

パスの書き方

• Windows ネイティブでは、ホーム相対パスにバックスラッシュも使える（~\work）
• Windows ネイティブでは、ドライブレターのパス（D:\work）と UNC パス（\\server\share）を絶対パスとして扱える
• :workspace_roots 配下のネストしたサブパスは workspace root の内側に留まる必要がある。../other-repo のような親への遡上は拒否される

deny と glob

• 近くの広いルールがアクセスを与えていても、読ませたくないファイル／部分木には deny を使う。~/.ssh のような安定した場所には正確なパス、リポジトリごとに位置が変わる機微ファイル群には glob が向く
• :workspace_roots 配下の glob は、有効な workspace root ごとの相対として解釈される
• deny の glob パターンは deny-read ルールとして対応している。read / write の glob は Linux / WSL / Windows ネイティブの sandbox で移植性が低いため、可能なら正確なパスや "docs/**" = "read" のような部分木ルールを使う
• Linux / WSL / Windows ネイティブでは、境界の無い ** の deny-read パターンは sandbox 起動前に境界付きの事前展開が必要になることがある。"**/*.env" = "deny" のようなパターンでは glob_scan_max_depth を設定する
• glob_scan_max_depth は最低 1。値を上げると sandbox 起動前により深くスキャンし、Linux / WSL / Windows ネイティブでは起動時の負荷が増える。境界付き展開を使いたくない場合は *.env、*/*.env、*/*/*.env のように深さを列挙する

network permissions

• enabled = true でその profile のネットワークアクセスを許可する。有効にすると既定ではフルのネットワーク挙動になるため、ほとんどの profile はドメインルールも定義すべきとされている
• ネットワーク sandbox proxy は既定でローカル listener にバインドされる。特定のランタイムと統合する場合を除き、listener 設定は既定のままにする
• dangerously_* のネットワークキーは特殊環境向けの escape hatch であり、通常のローカル開発で使うべきではない
• DNS rebinding とローカルサービスへの偶発アクセスへの防御として、既定でローカル／プライベートネットワークのガードが適用される。意図的に許すには正確なホストまたは IP リテラルを allowlist する
• allow_local_binding = true は、ローカル／プライベートアドレスに解決される allowlist 済みホスト名に到達する必要があるときにだけ設定する
• Unix socket proxying は Docker などのためのローカル escape hatch。deny は継承された allow エントリも含めて socket パスを拒否する。Unix socket を有効にするときは proxy listener を loopback にバインドしたままにする

強制の仕組み

profile が制御する範囲

• ローカルのコマンド実行のみ。connector、MCP サーバー、browser / computer-use の各サーフェス、Codex cloud の環境設定、承認された escalation はそれぞれ独自の制御を使う
• write 可能な profile は永続的な変更を作れる。スクリプト、ビルド手順、パッケージマネージャの hook、シェルの起動ファイル、共有ディレクトリへの書き込みは、後で別のツールやユーザーが元の sandbox の外で実行しうるため機微として扱う
• ネットワークのドメインルールは、network proxy を通る sandbox コマンドの通信先を制約する。許可した宛先が信頼できるかどうかを決めるものではなく、ワイルドカードの allow は広いまま
• ローカル／プライベートネットワークの宛先は既定でブロックされる

設定

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"
"*.github.com" = "allow"
"tracking.example.com" = "deny"

# 組み込みを拡張する
default_permissions = "project-edit"

[permissions.project-edit]
description = "Project editing with OpenAI API access."
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

# ワークスペースだけ書き込み可、他はすべて読み取り拒否
default_permissions = "workspace-only"

[permissions.workspace-only]
extends = ":workspace"

[permissions.workspace-only.filesystem]
":root" = "deny"
":minimal" = "read"
":tmpdir" = "deny"
":slash_tmp" = "deny"

# 境界の無い glob には glob_scan_max_depth を併用する
[permissions.project-edit.filesystem]
glob_scan_max_depth = 3

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

制約・注意点

• permission profile は Beta。仕様は変わりうる
• 1 セッションでは permission profile か旧 sandbox 設定のどちらか一方を使う
• 書き込みや outbound ネットワークを許すときは、タスクが完了する最も狭い profile を選ぶ。approval policy、秘密情報の扱い、allow ルールをそのアクセス水準に合わせる
• 組織の managed requirements は制限を追加でき、ユーザー設定でそれを緩めるべきではない
• グローバルな "*" の allow ルールは、パブリックネットワークアクセスを意図する場合にのみ使う

関連

• facts/codex/sandbox.md
• facts/codex/approvals-and-security.md
• facts/codex/configuration-reference.md
• facts/codex/config-basics.md