メインコンテンツへスキップ
       

Codexが起動しない「does not set default_permissions」の原因と直し方―config.tomlの権限プロファイル(AI作成)

第1 結論

Codexを起動しようとしたときに,「config defines [permissions] profiles but does not set default_permissions」と表示されて先へ進めない場合は,設定ファイルであるconfig.tomlの記載を確認する。
この表示は,config.tomlに権限プロファイル([permissions.名前]で始まる表)が書かれているのに,どのプロファイルを既定とするかを指定するdefault_permissionsが書かれていないことを示すものと考えられる。

直し方としては,次の二つが考えられる。
①config.tomlの最初の表の見出しより前に,default_permissions = “:workspace” のように,既定とするプロファイルを指定する1行を加える。
②権限プロファイルを使わないのであれば,[permissions.名前]で始まる表を削除し,従来のsandbox_modeによる設定に戻す。
もっとも,[permissions.network]のように,プロファイルとして書いたつもりのない表がある場合は,その表が「network」という名前のプロファイルとして読まれ,ネットワークの設定としては働かないと考えられるため,①の1行を加えるだけでなく,その表を削除するか,第4の2のように書き直す必要がある。

権限プロファイルは,OpenAIの公式資料上,ベータ版の機能とされ,仕様が変わる可能性がある。
本記事は,令和8年10月30日に確認したOpenAIの公式資料とGitHub上の報告に基づくものであり,個別のパソコンでの動作を保証するものではない。

第2 エラーが示していること

1 権限プロファイルとdefault_permissions

OpenAIの公式資料「Permissions」によれば,権限プロファイルは,Codexが利用者に代わって実行するコマンドについて,ファイルの読み書きの範囲と通信先をまとめて定める名前付きの設定である。
同資料は,組込みのプロファイルとして,読取りだけを許す「:read-only」,作業中のワークスペースの範囲等での書込みを許す「:workspace」,ローカルのサンドボックスの制限を外す「:danger-full-access」の三つを挙げている。

利用者が自分でプロファイルを作るときは,config.tomlに[permissions.名前]の表を書き,最上位のdefault_permissionsにそのプロファイル名又は組込みのプロファイル名を書く。
同資料の設定一覧では,default_permissionsの既定値は「None」(指定なし)とされ,予測可能な動作のために明示的に設定するよう求められている。

2 [permissions.network]と書いた場合

GitHubのopenai/codexリポジトリには,このエラーそのものを表題とする報告(Issue #14765,令和8年3月登録)がある。
報告者は,Linux上のCodex(報告された版は0.114.0)について,ネットワークの利用を許すつもりでconfig.tomlに[permissions.network]の表を書いたところ,Codexを起動しようとした時にこのエラーが表示されたと説明している。
他の環境や版でも同じ文言が表示されるかは,この報告からは分からない。

同じ報告に寄せられたコメント(令和8年3月)は,その投稿時点の設定の読込み処理が,[permissions]を名前付きプロファイルの表として扱い,default_permissionsが無い場合にはプロファイルの設定を受け付けないと説明している。
同コメントによれば,[permissions.network]と書くと,「network」という名前のプロファイルを定義したものとして読まれる。
したがって,ネットワークの設定を書いたつもりでも,プロファイルを一つ作り,その既定の指定を欠いた状態になる。

この報告は,令和8年10月30日の確認時点で未解決(open)であり,付いているコメントは利用者による1件だけである。
コメントの説明は利用者側の検証に基づくものであり,OpenAIの公式見解ではない点に注意を要する。

第3 config.tomlの場所

OpenAIの公式資料「Config basics」によれば,利用者ごとの設定はホームフォルダの「.codex」フォルダにあるconfig.tomlに保存される。
同資料は,プロジェクトごとの設定としてリポジトリ内の「.codex/config.toml」も読み込まれるが,それは利用者がそのプロジェクトを信頼済みとした場合に限られると説明している。

Windows版のChatGPTデスクトップアプリについて,公式資料「ChatGPT desktop app for Windows」は,Windows上のCodexと同じ「%USERPROFILE%\.codex」をCodexのホームフォルダとして使うと説明している。
そのため,Windowsで利用者ごとの設定を確認するときは,通常,「%USERPROFILE%\.codex\config.toml」を開くことになる。

設定の優先順位は,Config basicsでは,コマンドラインの指定,プロジェクトの設定,選択したプロファイルのファイル,利用者の設定の順に高いとされている。
利用者の設定を直してもエラーが消えない場合は,開いているプロジェクトの「.codex/config.toml」にも[permissions]の表がないかを確認する。

アプリが起動しない間は,アプリの画面から設定を開けないため,メモ帳等のテキストエディターでconfig.tomlを開く。
編集の前に,元のファイルを別名で複製しておく。

第4 直し方

1 組込みのプロファイルを既定にする

プロファイルの表を残したまま起動させたい場合は,config.tomlの最初の表の見出し(「[」で始まる行)より前に,次の1行を加える。
default_permissions = “:workspace”

TOMLの仕様では,表の見出しの後に書いたキーは,次の見出しまでその表に属し,最初の見出しより前に書いたキーだけが最上位の表(ルートテーブル)に属する。
ファイルの末尾や表の途中に書くと,最上位のdefault_permissionsとして扱われないため,最初の見出しより前に書く。

どの組込みプロファイルを選ぶかについて,公式資料は,ワークスペースの編集には「:workspace」,読取りだけの作業には「:read-only」を出発点として挙げている。
「:danger-full-access」は,ローカルのサンドボックスの制限を外すものであり,公式資料も,広い権限が意図したものである場合に限って使うよう注意している。
起動させることだけを目的に,最も広い権限を選ぶことは避けるべきである。

2 作ったプロファイルを既定にする

自分で作ったプロファイルを使う場合は,default_permissionsにその名前を書く。
例えば[permissions.project-edit]の表を作ったときは,default_permissions = “project-edit” と書く。

公式資料は,既存のプロファイルとほとんど同じ設定にしたいときは,extendsで組込みのプロファイルを引き継ぐことを勧めている。
extendsで「:workspace」を引き継ぐと,ワークスペース内の「.git」「.agents」「.codex」「.aws」を読取り専用とする基本の保護も引き継がれる。
引き継げるのは「:read-only」「:workspace」又は他の名前付きプロファイルであり,「:danger-full-access」は引き継げない。

ネットワークの利用を許したい場合は,[permissions.network]ではなく,プロファイル名の下に[permissions.プロファイル名.network]の表を作る。
公式資料によれば,network.enabled = true は通信を許すだけであり,通信先の制限(ドメインの許可・拒否)を働かせるには,別にfeatures.network_proxy = true を設定するか,管理者が管理用の設定(requirements.toml)の[experimental_network]で有効にする必要がある。

3 権限プロファイルを使わず従来の設定に戻す

権限プロファイルを使う必要がない場合は,[permissions.名前]で始まる表(その下位の表を含む。)を削除する方法もある。
公式資料は,権限プロファイル(default_permissionsと[permissions])と,従来のsandbox_mode等の設定は組み合わせず,どちらか一方を使うよう求めている。

公式資料は,読み込まれた設定ファイルのどこかにsandbox_modeがあれば,default_permissionsではなく従来の設定が使われると説明している。
しかし,GitHubには,macOS上のCodex CLI 0.146.0で反対にdefault_permissionsが優先されたという利用者の報告(Issue #36448,令和8年8月登録,未解決)もある。
同じ報告には,default_permissionsが無い設定でも,検証に使われたcodex sandboxが設定ファイルのsandbox_modeを適用しなかったという別の利用者のコメントもあり,原因は確定していない。
従来の設定に戻すときは,プロファイルの表だけでなく,default_permissionsの行も残さず削除しておくほうが,意図しない権限で動く危険が小さい。

第5 直した後に確かめること

1 起動と実際の権限

config.tomlを保存した後は,アプリを起動し直し,エラーが表示されないことを確かめる。
起動できた後も,意図した権限で動いているかを別に確かめる必要がある。

公式資料「Troubleshooting」は,自動承認の選択肢が表示されないか選べない場合の確認として,実際に有効な設定の中の権限プロファイル,承認の方針等を見直し,設定の優先順位を確かめるよう案内している。
権限プロファイルを直した後も,同じように実際に有効な設定を確かめることが考えられる。
読取り専用のはずの作業で書込みができないか,書き込めるはずの場所に書き込めるかを,重要でないファイルで試すと分かりやすい。

2 プロジェクトの設定が反映されないという報告

GitHubには,macOS上のCodexのデスクトップアプリが,プロジェクトの「.codex/config.toml」に書いたdefault_permissionsを適用せず,読取り専用で動いたという利用者の報告(Issue #22553,令和8年5月登録,未解決)もある。
同じ報告では,コマンドラインで同じプロファイルを明示すると適用されたとされている。
プロジェクトの設定で権限を変えた場合は,起動できたことだけで反映を確認したとせず,実際の動作で確かめる。

第6 組織が設定を管理している場合

企業等の管理者は,管理用の設定(requirements.toml等)で,利用者が選べる権限プロファイルを制限できる。
公式資料「Managed configuration」によれば,allowed_permission_profilesを置くと,そこに載っていないプロファイルは,組込みのものを含めて選べなくなる。

同資料は,管理者に対し,管理用の設定で許可したプロファイルの一つをdefault_permissionsとして明示するよう求めている。
また,同資料は,管理用の設定にdefault_permissionsの指定がない場合は,「:workspace」と「:read-only」の両方が明示的に許可されているときに限り,「:workspace」が既定となるとしている。

公式資料「Troubleshooting」は,組織又は端末の方針が選択肢を制限している場合,ローカルの設定でそれを覆すことはできないと説明している。
組織の管理下にあるパソコンで同じエラーが出る場合や,指定したプロファイルが使えない場合は,管理者に,許可されたプロファイルと既定の設定を確認する。

第7 法律事務所で設定を変えるときの注意

config.tomlは,AIエージェントが実行するコマンドの読み書きの範囲や通信先を左右する設定である。
起動しないことへの対処であっても,権限の範囲を変える作業として扱い,変更前の複製,変更した日時と変更者,変更の理由及び変更後の確認結果を記録しておきたい。

GitHubの報告(Issue #14765)では,エラーはCodexを起動しようとした時に表示されている。
そのため,アプリやAIエージェントが動いている間に設定ファイルを書き換えた場合は,次に起動するまで誤りに気付かないことがあると考えられる。
設定を変えた後は,業務の区切りで一度起動し直し,起動できること及び実際の権限を確かめておくと,急ぎの作業の途中で起動できなくなる事態を避けやすい。

AIエージェント自身に設定ファイルを書き換えさせる場合は,権限を広げる変更を人の承認なしに行わせないことが望ましい。
起動を回復させることと,権限を広げることは別の判断であり,「:danger-full-access」を選ぶ等の広い変更は,その必要性を確認した上で行う。

第8 関連記事

Codexで429エラーが表示される場合の原因の切り分けは,Codexで429エラーが出る原因と対策-別IP・別PCで回避できるか(AI作成)を参照されたい。

CodexがChromeに接続できない場合は,CodexがChromeに接続できないときの対処法―拡張機能,Computer Use,@Chrome及び新しいチャット(AI作成)を参照されたい。

AIエージェントが途中で止まった後の外部状態の確認と再開の手順は,法律事務所のAIエージェントが停止したときの再開手順-安全監視,プロンプトインジェクション,二重送信・二重公開及び証拠保全(AI作成)で扱っている。

サンドボックス,通信制限及び証拠保全の考え方は,法律事務所のAIサンドボックス入門-コンテナ,gVisor,MicroVM,通信制限,スナップショット及び証拠保全(AI作成)を参照されたい。

AIエージェントの導入・保守を外注する場合の検収と権限設定は,AIエージェントの導入・保守を外注するときの契約―検収,権限設定,更新及び障害対応(AI作成)で整理している。

第9 出典

①OpenAI「Permissions」(権限プロファイルの定義,組込みの三つのプロファイル,default_permissionsの既定値,extends,ネットワークの設定及び従来のsandbox_modeとの関係)
https://learn.chatgpt.com/docs/permissions

②OpenAI「Config basics」(利用者ごとの設定とプロジェクトの設定の場所,信頼済みプロジェクトの扱い及び設定の優先順位)
https://learn.chatgpt.com/docs/config-file/config-basic

③OpenAI「ChatGPT desktop app for Windows」(Windows版アプリが使うCodexのホームフォルダ)
https://learn.chatgpt.com/docs/windows/windows-app

④OpenAI「Troubleshooting」(実際に有効な設定の確認及び組織の方針とローカル設定の関係)
https://learn.chatgpt.com/docs/reference/troubleshooting

⑤OpenAI「Managed configuration」(allowed_permission_profiles及び管理者が定めるdefault_permissions)
https://learn.chatgpt.com/docs/enterprise/managed-configuration

⑥GitHub openai/codex Issue #14765「config defines [permissions] profiles but does not set default_permissions」
https://github.com/openai/codex/issues/14765

⑦GitHub openai/codex Issue #36448「Docs and behavior disagree: default_permissions overrides sandbox_mode」
https://github.com/openai/codex/issues/36448

⑧GitHub openai/codex Issue #22553「Codex Desktop does not apply project-local default_permissions from .codex/config.toml」
https://github.com/openai/codex/issues/22553

⑨TOML v1.0.0(表の見出しとキーの所属及びルートテーブル)
https://toml.io/en/v1.0.0

いずれも令和8年10月30日に確認した。