config / overview · 約 6 分

config.toml の場所

ユーザー設定とプロジェクト設定、trusted の意味を把握します。

学習目標

ユーザー設定は ~/.codex/config.toml、プロジェクトは .codex/config.toml です。プロジェクト層は信頼済みのときだけ読みます。 ^{[codex-config-basic]}

前提

hello-codex-school 相当の workspace があること。

なぜ必要か

毎回フラグを付けるより、学習用の既定をファイルに置く方が再現できます。

実行場所

Web実習 (browser) では WebContainer の実 FS で TOML を編集できます。Codex がプロジェクト設定を読むのは local-bridge で、workspace が trusted なときだけです。

project を trusted にする手順(対話)

個人の ~/.codex/config.toml を手編集せず、対話の信頼プロンプト経由を正とします。

1. workspace ディレクトリで対話 codex を起動する。
2. 初回なら project を信頼するか の選択が出るので承認する。
3. /exit などでいったん終了する。
4. .codex/config.toml を作成または編集する(このレッスンの starter)。
5. もう一度 codex を起動し直し、/status で sandbox_mode など実有効値を確認する。

--ignore-user-config は既存の trust も読まれないことがあるので、通常の学習起動には使いません。 ^{[codex-config-basic]}

このレッスンの check はファイル内容(存在と TOML キー)だけを見ます。ファイルがあることは設定が効いている証拠ではありません。 実効の確認は /status(または信頼後のセッションでの実有効値)です。既存 schema では対話 /status の安定な自動判定ができないため、ここは手動確認です。

モデルはファイルに固定しません。対話の /model で、そのアカウントに出る候補から選びます。

優先順位は高い順に、CLI フラグ、プロジェクト config、profile ファイル、ユーザー config、クラウド管理、システム、組み込みです。 ^{[codex-config-basic]}

プロジェクトでは notify や model_providers など、資格情報やホスト固有キーは無視されます。 ^{[codex-config-ref]}

後の章で同じ .codex/config.toml にキーを足すときは、全文置換せず追記・統合します。少なくとも [features] hooks = true や既存の mcp_servers を消さないでください。

成功結果

.codex/config.toml に sandbox_mode = "workspace-write" があります。上記の trust → 終了 → 設定 → 起動し直しのあと、/status にその sandbox が実有効値として出ます。

失敗対処

効かないときはプロジェクトが untrusted です。ユーザー設定だけが残ります。上記の信頼選択と起動し直しをやり直してください。 ^{[codex-config-basic]}