Codex│config.tomlの場所と書き方｜モデル・承認・サンドボックスの設定と優先順位

Codexの設定は、config.toml というファイルに書きます。

ローカルのCLI・IDE拡張機能・デスクトップアプリは設定ファイルを共有できます。ただし、機能ごとの対応や画面で選んだ設定により、すべての項目が同じように適用されるとは限りません。

• 自分の設定：ホームフォルダの .codex/config.toml
• プロジェクトの設定：プロジェクトの .codex/config.toml（信頼したプロジェクトだけ読まれる）
• その回だけ変える：codex -c 項目=値
• 主な実行設定の確認：codex exec の開始時表示（全設定の一覧ではない）

2026年10月23日に公式資料とWindowsのCLIヘルプを再照合しました。実行結果の例は2026年9月29日のCodex CLI 0.158.0での記録で、今回の再実行結果ではありません。

config.tomlの場所

設定フォルダの場所は、環境変数 CODEX_HOME で変えられます。

優先順位

通常の設定値は、以下の優先順位で決まります。管理者が強制するrequirements.tomlなどの制限は別で、コマンド指定でも禁止された承認・サンドボックス設定には変更できません。

1. コマンドの指定（-c・--config など）
2. プロジェクトの .codex/config.toml（今いるフォルダに近いものが勝つ）
3. --profile で選んだプロファイル
4. ユーザーの config.toml
5. ワークスペースの管理者が決めた初期値
6. システムの設定
7. Codexの初期値

CLI 0.158.0での確認記録

本文の実行例では、開始時にモデル・承認・サンドボックスなどが表示されました。全設定の一覧ではありません。また、codex execは設定表示専用ではなく、入力した作業を実行して利用枠を消費します。

codex exec --skip-git-repo-check "こんにちは、とだけ答えて"

OpenAI Codex v0.158.0
--------
workdir: C:\demo\codex-demo
model: gpt-6-astra
provider: openai
approval: never
sandbox: read-only
reasoning effort: medium
reasoning summaries: none
--------

これはユーザーの config.toml の設定です。

プロジェクトの設定は、信頼するまで効かない

練習用のフォルダに、次の .codex/config.toml を置きました。

model_reasoning_effort = "low"
sandbox_mode = "workspace-write"

置いただけでは、表示は reasoning effort: medium、sandbox: read-only のまま変わりませんでした。

そのフォルダを信頼済みにすると、プロジェクトの設定が使われました。

approval: never
sandbox: workspace-write [workdir, /tmp, $TMPDIR]
reasoning effort: low

信頼したフォルダは、ユーザーの config.toml に次のように記録されます。

[projects.'c:\demo\codex-demo']
trust_level = "trusted"

ふつうは、初めてそのフォルダで Codex を開いたときの確認で「信頼する」を選ぶと書き込まれます。

-cでその回だけ変える

codex exec -c model_reasoning_effort='"high"' "こんにちは、とだけ答えて"

sandbox: read-only
reasoning effort: high

-cの値はまずTOMLとして解析され、解析できなければ文字列として扱われます。引用符の渡し方はシェルでも変わるため、配列や空白を含む値は公式の引用符の例と使用中のシェルを確認してください。

よく使う設定項目

書き方の例です。

model_reasoning_effort = "medium"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
web_search = "cached"

[sandbox_workspace_write]
network_access = false

danger-full-access は、Codexのサンドボックスによる制限を外します。OSの権限は残り、承認設定も別項目です。

使うのは、ほかの方法で隔離された環境の中だけにします。

config.tomlでよくあるエラー

当方の環境では、古いコマンド版を動かしたときに次のエラーが出て止まりました。

Error loading configuration: C:\Users\（ユーザー名）\.codex\config.toml:6:16: unknown variant `default`, expected `fast` or `flex`

6行目の service_tier = "default" という値を、古い版（0.128.0）が知らなかったためです。

この値は、新しいデスクトップアプリが書いたものでした。

この過去事例ではCLIの更新で解消しました。npmで導入したCLIには本文のnpm更新コマンドを使えます。別の導入方法なら、その方法に対応した更新手順を確認してください。

npm install -g @openai/codex@latest

エラーには、ファイル名・行・文字の位置が出るので、その場所を見れば原因の項目が分かります。

デスクトップアプリとコマンド版を両方使うなら、コマンド版も新しくしておきます。

まとめ

• 自分の設定はホームの .codex/config.toml
• プロジェクトの .codex/config.toml は、信頼したフォルダでしか読まれない
• 強い順は、コマンドの指定 → プロジェクト → プロファイル → ユーザー
• codex exec の開始時表示では、モデルなど一部の実行設定を確認できる
• unknown variant のエラーは、版が古いときにも出る

参考：公式Config basics・Configuration Reference（2026年10月23日照合）。

よくある質問：Codexのconfig.toml

Codexの設定ファイル config.toml は、どこにありますか？

ユーザー用はホームフォルダの .codex/config.toml（Windowsは %USERPROFILE%\.codex\config.toml）で、いつも読まれます。

プロジェクト用はプロジェクトの .codex/config.toml で、そのプロジェクトを信頼しているときだけ読まれます。

プロファイルは設定フォルダの（名前）.config.toml で、--profile 名前 で選んだときだけ読まれます。

設定フォルダの場所は、環境変数 CODEX_HOME で変えられます。

CLI、IDE、デスクトップアプリで、設定は共通ですか？

共通です。

ローカルのCLI・IDE拡張機能・デスクトップアプリは設定ファイルを共有できます。ただし、機能ごとの対応や画面で選んだ設定により、すべての項目が同じように適用されるとは限りません。

同じ項目が複数の場所にあると、どれが勝ちますか？

通常の設定値は以下の順です。管理者による強制制限は、この上書き順とは別に適用されます。

強い順に、コマンドの指定（-c・--config など）、プロジェクトの .codex/config.toml（今いるフォルダに近いものが勝つ）、--profile で選んだプロファイル、ユーザーの config.toml、ワークスペースの管理者が決めた初期値、システムの設定、Codexの初期値です。

プロジェクトの .codex/config.toml を置いたのに、効かないのはなぜですか？

未信頼のプロジェクトでは読み込まれません。信頼済みなら、作業ディレクトリ・CODEX_HOME・優先されるコマンド指定・管理者制限も確認してください。

記事の確認では、置いただけでは表示が変わらず、信頼済みにするとプロジェクトの設定が使われました。

信頼したフォルダは、ユーザーの config.toml に記録され、ふつうは初めてそのフォルダで Codex を開いたときの確認で「信頼する」を選ぶと書き込まれます。

今の設定を、確かめるには？ その回だけ変えるには？

本文の実行例では、開始時にモデル・承認・サンドボックスなどが表示されました。全設定の一覧ではありません。また、codex execは設定表示専用ではなく、入力した作業を実行して利用枠を消費します。

その回だけ変えるなら、codex -c 項目=値 を使います。

-cの値はまずTOMLとして解析され、解析できなければ文字列として扱われます。引用符の渡し方はシェルでも変わるため、配列や空白を含む値は公式の引用符の例と使用中のシェルを確認してください。

よく使う設定項目には、何がありますか？

model（使うモデル）、model_reasoning_effort（考える深さ）、approval_policy（コマンドを実行する前に確認するか。on-request・never など）、sandbox_mode（read-only・workspace-write・danger-full-access）、sandbox_workspace_write.network_access（workspace-write のときにネットを使うか）、web_search（disabled・cached・indexed・live）、service_tier（処理の速さの区分）、history.persistence（history.jsonlに履歴を残すか）、project_doc_max_bytes（AGENTS.md を読む上限）などです。

danger-full-access は、使ってよいのですか？

Codexのサンドボックスによる制限を外します。OSの権限は残り、承認設定も別項目です。

使うのは、ほかの方法で隔離された環境の中だけにします。

config.toml で、エラーが出て止まるときは？

記事の環境では、古いコマンド版（0.128.0）が、新しいデスクトップアプリが書いた service_tier の値を知らず、エラーで止まりました。

この過去事例ではCLIの更新で解消しました。npmで導入したCLIには本文のnpm更新コマンドを使えます。別の導入方法なら、その方法に対応した更新手順を確認してください。

エラーにはファイル名・行・文字の位置が出るので、その場所を見れば原因の項目が分かります。

デスクトップアプリとコマンド版を両方使うなら、コマンド版も新しくしておきます。

本文の実行例は2026年9月29日のCLI 0.158.0の記録です。2026年10月23日の更新では公式資料とCLIヘルプを照合し、設定変更を伴う再実行はしていません。

最新は公式ページで確認してください。