config.toml 設計 - モデル・承認・サンドボックス・プロファイル

config.toml は Codex の実行方法を制御します。AGENTS.md が文章による作業契約であるのに対し、config.toml はモデル、承認方針、サンドボックス、MCP、Hooks、Subagents などの機械的な設定を持ちます。

設定レイヤー

代表的な読み込み順は、優先度が高い順に次のとおりです。

1. CLI フラグと --config
2. 信頼済みプロジェクトの .codex/config.toml
3. --profile で選んだプロファイル
4. ~/.codex/config.toml
5. /etc/codex/config.toml などのシステム設定
6. 組み込み既定値

個人の通知や認証に近い設定はユーザー層、チームで共有する承認やプロジェクト機能はプロジェクト層へ置きます。秘密情報をプロジェクト設定へ直接書いてはいけません。

最小設定例

model = "gpt-5.5"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

[features]
hooks = true

この例では、通常はワークスペース内だけを書き込み可能にし、追加権限が必要な操作は承認を求めます。モデル名や利用可能な機能は変更されるため、設定時点の公式リファレンスを確認してください。

プロファイルで用途を分ける

調査、実装、CI では必要な権限が異なります。用途別のプロファイルファイルを $CODEX_HOME（通常は ~/.codex）へ作ると、毎回多数のフラグを指定せずに済みます。

# ~/.codex/review.config.toml
sandbox_mode = "read-only"
approval_policy = "on-request"

# ~/.codex/implementation.config.toml
sandbox_mode = "workspace-write"
approval_policy = "on-request"

レビュー時は codex --profile review、実装時は codex --profile implementation のように選択します。

信頼境界を意識する

Codex は信頼していないプロジェクトの .codex/ レイヤーを読み込みません。これは、取得しただけのリポジトリに悪意のある Hooks や設定が含まれている場合に、自動実行されることを防ぐためです。

設定変更後は次を確認します。

• 目的より広い書き込み・ネットワーク権限がない
• danger-full-access を常用していない
• プロジェクト設定にトークンや個人パスがない
• Rules と古いサンドボックス設定が矛盾していない

次は Rules ファイル設計 で、個別コマンドの扱いを宣言します。

このページの外部仕様・背景情報は、参考文献を参照してください。[1][2]

参考文献

1. OpenAI, Codex documentation
2. OpenAI, OpenAI API documentation