Codex config.tomlの変更が効かない場合でも、通常はTOMLファイルが破損しているわけではありませんが、設定がより高い優先度で上書きされているため、プロジェクトはまだ信頼されていないか、古いセッションがまだ起動設定を使っている場合です。 まず、どのレイヤーに変えるかを確認し、その後調査を続けてください。
まず、実際の設定優先度と比較してください
コデックスは同名の設定を、高い順から低い順に解析します。
- 現在のコマンドパラメータと
-c key=value; - プロジェクト内では、リポジトリのルートディレクトリから現在のディレクトリへレイヤーごとにロード
.codex/config.tomlし、現在のディレクトリに最も近い値を優先します。 --profile選択された個人構成;- ユーザーレベル
~/.codex/config.toml; - Unixシステムレベルの
/etc/codex/config.toml; - 組み込みのデフォルト値。
例えば、ユーザーがsandbox_mode = "workspace-write"を指定するが、起動コマンドに--sandbox read-onlyがある場合、この操作はコマンドラインに従っていなければなりません。 ウェアハウスプロジェクトの構成はユーザー設定を上書きします。
一度限りのパラメータで構成層を特定します
まず、同じ設定をコマンドラインで一時的に上書きします。 一時的な値が有効な場合、Codexはこの構成をサポートしており、問題はファイルの位置、優先度、または信頼状態に焦点が当てられています。
codex -c model_reasoning_effort="high"次に、厳格な設定チェックを用いて、現在のバージョンが見慣れないフィールドに遭遇した際に直接エラーを報告するようにします。
codex --strict-config機能スイッチはアクティブステータスのcodex features listチェックに使用できます。 ワーキングディレクトリとサンドボックスの範囲はセッション内でチェックされます/status。
プロジェクト構成が完全に無視されたら、信頼の状態を確認してください
信頼できないプロジェクトは、プロジェクト内の.codex/構成レイヤー(プロジェクトフックやルールを含む)を読み込みません。 この時点でユーザーレベルの設定はまだ読み込まれるので、一般的な表示は「グローバル設定は動作しますが、倉庫設定は無効です」です。 正しいリポジトリのルートディレクトリが開かれているか確認し、その後、スタートアッププロンプトや/permissionsで信頼されたディレクトリを確認してください。
組織化された装置もまた、requirements.toml制約の対象となることがあります。 管理者によって禁止されたサンドボックスや承認モード、個人設定は強制的に上書きできません。 この時点で、組織戦略を見直すべきです。 最後に、新しいCLIセッションを開くか、IDE拡張をリロードして、検証前に位置を一つずつ調整してください。
