Codexの設定とは？config.tomlの場所・主な項目・変え方を解説

「Codexのモデルを変えたい」「確認の画面を減らしたい」「設定ファイルがどこにあるのか分からない」「ネットで見た設定を書いたのに効かない」。Codexを使い込むほど、設定まわりで迷う場面が増えてきます。

Codexの設定は、画面の設定、設定ファイル（config.toml）、起動時のオプションやスラッシュコマンドの3つの入口から変えられます。入口ごとに得意なことが違い、同じ項目が複数の場所に書かれているときは、決まった順番で優先されます。この仕組みを知っておくと、「なぜ効かないのか」を自分で切り分けられるようになります。

この記事では、設定の全体像、設定ファイルの場所と優先順位、よく使う項目、画面ごとの設定、承認とサンドボックスの設定、切り替えの方法、効かないときの確認手順を順に解説します。内容は2026年10月時点の公式ドキュメントをもとにしています。設定項目は追加や変更が続いているため、細かい仕様は公式の設定リファレンスもあわせて確認してください。

Codexの設定の全体像

Codexには、ChatGPTのデスクトップアプリ、ターミナルで使うCLI、エディタに入れるIDE拡張という複数の使い方があります。設定の入口もこれに合わせていくつかありますが、中身は共通の設定ファイルに集まると考えると整理しやすくなります。

config.tomlとは

config.tomlは、Codexの設定を書いておく文章ファイルです。「TOML」という、人が読み書きしやすい形式で書きます。公式ドキュメントでは、CLIとIDE拡張が同じ設定の層を共有していると説明されています。Windowsのアプリも、ネイティブ版のCodexと同じCodexのホームフォルダを使います。

設定ファイルでできることとして、公式では次の3つが最初に挙げられています。

• 既定のモデルとプロバイダー（接続先）を決める
• 承認の方針とサンドボックスの設定を決める
• MCPサーバー（外部のツールやデータにつなぐ仕組み）を設定する

実際にはこれ以外にも、見た目や通知、履歴、フック、サブエージェントなど、多くの項目が書けます。全項目は公式の設定リファレンスに一覧があります。

書き方の基本

TOMLは「項目名 = 値」の形で書きます。文字列は引用符で囲み、真偽はtrue・falseと小文字で書きます。行頭の#はコメントで、Codexには読まれません。

# ~/.codex/config.toml の例
model = "gpt-6.1-sol"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
web_search = "cached"

[features]
memories = true

角かっこで囲んだ[features]は「テーブル」と呼ばれるまとまりで、その下に書いた項目はまとまりの中の設定になります。公式のサンプルにも書かれているとおり、テーブルに属さない項目は、最初のテーブルより前に書く必要があります。[features]の後ろにmodel = ...を書くと、featuresの中の項目として読まれてしまいます。

設定ファイルの場所と優先順位

設定ファイルは1か所ではなく、役割の違う複数の場所に置けます。まず、どこに何を置くのかを整理します。

Codexの状態を保存する場所はCODEX_HOMEという環境変数で決まり、指定しなければ~/.codexです。CODEX_HOMEを自分で指定する場合は、フォルダがあらかじめ存在している必要があると公式に書かれています。このフォルダには、設定のほかに認証情報、履歴、ログ、スキルなどが入ります。

優先順位

同じ項目が複数の場所に書かれているときは、次の順番で決まります。上にあるほど優先されます。

たとえば、ユーザーの設定でmodel = "A"、あるプロジェクトの設定でmodel = "B"と書いてあれば、そのプロジェクトで作業するときだけBが使われます。さらにcodex --model Cで起動すれば、その回だけCになります。

プロジェクトの設定が複数ある場合は、プロジェクトのルートから作業中のフォルダまでの.codex/config.tomlがすべて読み込まれ、同じ項目は作業中のフォルダに近いファイルが勝ちます。プロジェクトのルートは、既定では.gitがあるフォルダです。

管理者の「要件」は別の層

会社のPCでは、管理者がrequirements.tomlなどで制限をかけていることがあります。公式の説明では、要件は「できることの範囲」を縛り、設定値は「その範囲の中での既定値」を決めるものです。たとえば要件でapproval_policy = "never"が禁止されていれば、config.tomlに書いても反映されません。

「書いたのに変わらない」ときは、要件で制限されている可能性があります。確認の方法は、後半の「設定が効かないとき」で紹介します。

プロジェクトの設定を信頼するかどうか

プロジェクトの.codex/フォルダには、設定だけでなくフックやルールも入れられます。そのため、Codexは信頼したプロジェクトのときだけ、このフォルダを読み込みます。公式の説明では、信頼しないプロジェクトでは、プロジェクト内の設定・フック・ルールがすべて読み飛ばされます。ユーザーとシステムの設定は、そのまま読み込まれます。

設定ファイルの開き方

IDE拡張では、右上の歯車アイコンから「Codex Settings」を選び、「Open config.toml」を選ぶと、いま使っている設定ファイルが開きます。アプリとCLIでは、上の表の場所にあるファイルをエディタで開きます。

公式ドキュメントには、設定ファイルが最初から存在するかどうかや、新しく作る手順の説明はありません。見つからないときは、IDE拡張の「Open config.toml」を使うか、同じ名前のファイルを上の場所に作ってから、Codexを開き直して/statusなどで確かめてください。

よく使う設定項目

設定項目は非常に多いのですが、日常的に触るのは数個です。公式の「Config basics」で「最も変更されることが多い」と紹介されているものを中心に、表にまとめます。

モデルの選び方や、考える深さの目安は「Codexのモデル」の記事で詳しく解説しています。ここでは、設定ファイルでの書き方に絞って紹介します。

モデルと考える深さ

モデルに関する項目は、modelとmodel_reasoning_effortのほかにもあります。公式の設定リファレンスでは、次のような項目が載っています。

高速モード（Fast）は、対応するモデルの速度を上げる代わりに、使用量を多く消費します。公式の「Speed」のページでは、対象のモデルでは、サブスクリプションに含まれる使用量を標準の2.5倍で消費すると説明されています。常用する設定にする前に、使用量への影響を確かめてください。使用量の確認方法は「Codexの使用量の確認」の記事で解説しています。

Web検索の方式

Web検索は、既定で有効です。ただし既定の方式は、リアルタイムのWebを見に行くものではなく、OpenAIが維持している検索用のインデックス（キャッシュ）から結果を返す方式です。公式では、任意のWebページから指示が紛れ込むリスク（プロンプトインジェクション）を減らすためと説明されています。

注意したいのは、--yoloなどのフルアクセスのサンドボックス設定にすると、Web検索の既定がliveに変わる点です。承認とサンドボックスを緩めるときは、Web検索の方式も一緒に見直してください。

指示と記憶

Codexへの指示は、基本的にはAGENTS.mdに書きます。設定ファイルには、それを補う項目があります。

日常の指示は、AGENTS.mdに書くのが基本です。model_instructions_fileは組み込みの指示を置き換えるため、特別な理由がなければ使わないほうが安全です。AGENTS.mdの書き方や読み込まれる順番は「AGENTS.mdの書き方」の記事にまとめています。

機能のオン・オフ（features）

設定ファイルの[features]では、機能ごとのオン・オフを切り替えられます。公式の「Config basics」に載っている主なものは次のとおりです。

機能をオンにする方法は3つあります。config.tomlの[features]に機能名 = trueと書く方法、起動時にcodex --enable 機能名と指定する方法、codex features enable 機能名で設定ファイルに保存する方法です。codex features listで、機能の一覧と、いまの状態を確認できます。

最初に整えるときの設定例

個人で使い始めるときの設定ファイルの例です。モデルは、自分のアカウントで使えるものに書き換えてください。公式のサンプルが示している値のうち、基本的なものだけを書いています。

# ~/.codex/config.toml
model = "gpt-6.1-sol"          # 自分のアカウントで使えるモデルに変える
model_reasoning_effort = "medium"
approval_policy = "on-request"  # 必要なときに確認を求める
sandbox_mode = "workspace-write" # 作業フォルダの中だけ書き込める
web_search = "cached"           # 既定のWeb検索

[sandbox_workspace_write]
network_access = false          # コマンドの外部通信は許可しない

この例は、公式が「Auto」と呼ぶ標準的な組み合わせ（作業フォルダの中は自動、外への書き込みやネットワークは確認）に相当します。まずはこの状態で使い、困った点が出てから項目を足していくのがおすすめです。

画面ごとの設定とコマンド

設定ファイルを触らなくても、アプリ・IDE拡張・CLIのそれぞれに設定の入口があります。ここでは、画面ごとに何を変えられるのかを整理します。

ChatGPTデスクトップアプリ

アプリの設定は、メニューから「Settings」を開くか、WindowsではCtrl+,、MacではCmd+,で開きます。公式の設定ページに載っている項目は次のとおりです。

公式の設定ページには、モデルや承認、サンドボックスの項目は載っていません。これらは、設定ファイルで変えます。

IDE拡張

IDE拡張の設定は、2つの層に分かれています。公式の説明では、次のとおりです。

• Codexの設定：モデル、考える深さ、権限、サンドボックス、MCPサーバーなど。config.tomlから読み込まれ、CLIと共通
• エディタの設定：拡張がエディタの中でどう動くか。chatgpt.*という名前で、エディタ自身の設定の仕組みに保存される

Codexの設定は、サイドバーの歯車アイコンから「Codex Settings」で開きます。エディタの設定は、エディタの設定画面で@ext:openai.chatgptや「Codex」で検索して変えます。主な項目は次のとおりです。

公式には、chatgpt.*の項目はIDE拡張のものであり、config.tomlには書かないと明記されています。WSLで使う場合の違いは「Windowsでの使い方」の記事で解説しています。

CLIのスラッシュコマンド

CLIでは、対話中にスラッシュコマンドで設定を変えられます。公式のコマンド一覧によると、設定ファイルに保存されるものと、そのセッションだけのものがあります。

ほかにも、/importで、Claude CodeやCursorの設定・プロジェクト・チャットを取り込めます。コマンドの一覧は、公式の「Slash commands in Codex CLI」のページにあります。

ターミナルの表示と通知（tui）

CLIの画面まわりの設定は、[tui]というテーブルにまとまっています。公式のリファレンスに載っている主な項目は次のとおりです。

長い作業を任せている間に別の作業をすることが多い方は、notificationsとnotification_conditionを見直すと、完了に気づきやすくなります。

日本語で使うときの設定

「Codexを日本語で使いたい」という場合は、画面の言語と返答の言語を分けて考えます。

返答の言語を固定したいときは、AGENTS.mdに「回答は日本語で書く」のように書いておく方法が確実です。アプリの「Settings」の「Personalization」からは、個人用のAGENTS.mdを編集できます。リポジトリのAGENTS.mdに書けば、そのプロジェクトで作業する人全員に反映されます。

# AGENTS.md の例
- 回答と説明は日本語で書く。
- 専門用語は、初めて出てきたときに短く説明する。
- コードのコメントは日本語で書く。

設定ファイルのdeveloper_instructionsにも、同じ内容を書けます。ただし、複数のプロジェクトで共通にしたいだけなら、個人用のAGENTS.mdのほうが管理しやすくなります。

承認とサンドボックスの設定

設定のなかでも、仕事で使うなら最初に理解しておきたいのが、承認とサンドボックスです。Codexの安全性は、次の2つの層で決まります。

• サンドボックス：コマンドを実行するときに、技術的に何ができるか（どこに書き込めるか、ネットワークに出られるか）
• 承認の方針：どんなときに、実行の前に人へ確認を求めるか

この2つは別々の設定で、組み合わせて使います。公式の説明では、CLIとIDE拡張はOSの仕組みでサンドボックスを強制し、既定ではネットワークアクセスなし・書き込みは作業中のワークスペースの中だけになっています。

承認の方針（approval_policy）

granular（細かい指定）では、sandbox_approval（サンドボックスの外への実行）、rules（ルールによる確認）、mcp_elicitations（MCPからの確認）、request_permissions（権限の要求）、skill_approval（スキルのスクリプト）の5種類を、それぞれtrue・falseで指定します。trueにした種類は確認が表示され、falseにした種類は自動で拒否されます。

サンドボックスのモード（sandbox_mode）

公式の説明では、起動時にCodexがフォルダの状態を見て、Gitで管理されているフォルダでは「Auto」（workspace-writeとon-request）を、そうでないフォルダではread-onlyを勧めます。また、設定によっては、作業フォルダを信頼するまでread-onlyで始まることもあります。なお、公式のサンプル設定では、sandbox_modeの既定値がread-onlyと書かれています。実際にどの状態で始まったかは、/statusで確かめられます。

よく使う組み合わせ

公式は、最後の「すべて許可」を推奨していません。使う場合は、環境そのものが隔離されているかを必ず確認してください。

ネットワークと書き込み先の設定

workspace-writeのときにコマンドから外部へ通信させたい場合は、[sandbox_workspace_write]で許可します。書き込める場所を追加することもできます。

[sandbox_workspace_write]
network_access = true                 # 外部への通信を許可する
writable_roots = ["/Users/YOU/.pyenv/shims"]  # 書き込める場所を足す

ここで許可するのは、コマンドの通信です。Web検索、アプリ（コネクタ）、MCPサーバーは別の制御になっており、コマンド用のネットワーク設定では制限されないと、公式に注意書きがあります。

コマンドに渡す環境変数を絞る

Codexが実行するコマンドには、自分のパソコンの環境変数が渡されます。APIキーなどの秘密情報が環境変数に入っている場合は、[shell_environment_policy]で渡す範囲を絞れます。

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"

見落としやすいのは、ignore_default_excludesの既定がtrueである点です。trueのままだと、名前にKEY・SECRET・TOKENを含む変数の自動の除外が行われません。自動の除外を使いたいときは、falseに変えます。

Windowsで、サンドボックスの方式を選ぶ設定（[windows]のsandboxや、featuresのprefer_mxc）は「Windowsでの使い方」の記事で解説しています。

プロファイルとプロジェクトの設定

用途によって設定を使い分けたいときは、プロファイル、プロジェクトの設定、1回だけの上書きを使い分けます。

プロファイルで切り替える

プロファイルは、名前をつけた設定の層です。--profile 名前を付けて起動すると、まず~/.codex/config.tomlが読み込まれ、その上に~/.codex/名前.config.tomlが重なります。ファイルには、基本の設定と違う項目だけを書けば足ります。

# ~/.codex/review.config.toml
model = "gpt-6.1-sol"
model_reasoning_effort = "medium"
approval_policy = "on-request"
sandbox_mode = "read-only"

codex --profile review
codex exec --profile review "この変更をレビューして"

プロファイル名には、英数字・ハイフン・アンダースコアが使えます。ファイルの中では、項目を最上位にそのまま書き、[profiles.名前]の中には入れません。

1回だけ上書きする（-c）

設定ファイルを書き換えずに、その回だけ変えたいときは、専用のオプションがあればそれを使い、無ければ-c（--config）を使います。

codex --model gpt-6.1-sol
codex -c sandbox_workspace_write.network_access=true
codex -c log_dir=./.codex-log

入れ子の項目は、ドット（.）でつないで書けます。値はTOMLとして読み取られ、TOMLとして読めない場合は文字列として扱われると公式に書かれています。そのため、モデル名のような文字列は、引用符なしでも指定できます。配列や表を渡すときは、シェルが空白で分割しないように、全体を引用符で囲んでください。

公式の例は、Mac・Linuxのシェルを前提にした書き方です。PowerShellでは引用符の扱いが異なるため、複雑な値は設定ファイルに書くほうが確実です。

プロジェクトの設定で、チームの標準をそろえる

リポジトリの.codex/config.tomlに設定を書いておけば、そのリポジトリで作業するときだけ効く設定になります。プロジェクト内の相対パス（たとえばmodel_instructions_file）は、その.codex/フォルダを基準に解決されます。

ただし、安全のため、プロジェクトの設定では上書きできない項目があります。公式では、認証の接続先や通知・テレメトリー（利用状況の送信）に関わる項目が挙げられており、次の項目は無視されて、起動時に警告が出ます。

チームで設定をそろえたい場合、リポジトリに.codex/config.tomlを置く方法と、管理者が配る方法（Team Config、管理設定）があります。リポジトリに置く場合は、秘密情報を書かないことを徹底してください。

使い分けの目安

設定が効かないとき

「config.tomlに書いたのに変わらない」ときは、原因を順番に切り分けます。闇雲に書き直す前に、Codexが実際に何を読み込んでいるのかを確かめるのが近道です。

確認の順番

1. /statusで、いまの状態を見るCodexの中で/statusと入力します。使用中のモデル、承認の方針、書き込める場所、残りの使用量が表示されます。意図した設定になっているかを、まずここで確かめます。
2. /debug-configで、設定の層を見る/debug-configは、設定の層の順番（優先順位の低いほうから）、各層のオン・オフ、管理者の要件の出どころを表示します。「なぜ設定ファイルの値と違うのか」を調べるためのコマンドです。
3. codex doctorで、環境を診断するターミナルでcodex doctorを実行すると、インストール、設定、認証、実行環境、Git、ターミナルなどの診断レポートが出ます。
4. 管理者に確認する要件や管理設定で制限されている場合は、自分では変えられません。/debug-configの出力を添えて、管理者に相談します。

症状から探す

古い記事の設定を書き換える

ネットの記事には、過去のバージョンの書き方が残っています。公式のリファレンスで、書き換えを求められている主なものを表にまとめます。

ログと環境変数で調べる

原因が分からないときは、ログを残して調べます。log_dirを指定すると、codex-tui.logが保存されます。公式の例では、次のように一時的に指定しています。

RUST_LOG=debug codex -c log_dir=./.codex-log

この書き方はMac・Linuxのシェル向けです。PowerShellでは、先に$env:RUST_LOG='debug'と環境変数を設定してから、codex -c log_dir=./.codex-logを実行します。なおcodex execでは、メッセージが別のログファイルではなく、画面にそのまま表示されます。

設定に関係する主な環境変数は、次のとおりです。

よくある質問

まとめ

設定は、一度に完璧にそろえようとせず、モデルと承認の2つから始めて、困ったことが出てきたら項目を足していくのが現実的です。変更は1つずつ、元に戻せる形で行ってください。

社内で使うとなると、承認の方針、プロジェクトの設定、秘密情報の扱い、メンバーへの説明など、決めることが一気に増えます。INTERCREATE JAPANでは、Claude CodeやCodexの導入から、社内の標準設定づくり、使い続けられる仕組みづくりまでをお手伝いしています。