Codex 上級設定
Codex CLICodex の上級設定レイヤーにより、モデルプロバイダー、サンドボックス権限、Hooks フック、テレメトリーデータ、ターミナル動作を細かく制御できます。
Codex に初めて触れる場合は、まず次のドキュメントを読んでください。Config basics（設定の基本）全体像を把握してください。本記事では、あなたが次のことを理解していることを前提としています。~/.codex/config.tomlの存在と役割を。
設定階層の全体像
Codex の設定は複数レイヤーが重なり合って構成されています。この点を理解することが、以降のすべての上級テクニックの基盤です。
下位層から上位層の順に、システム層 → ユーザー層（~/.codex/config.toml） → Profile 層 → プロジェクト層（.codex/config.toml） → CLI コマンドライン引数。
上位層は下位層の同名設定を上書きします。現在の作業ディレクトリに最も近いプロジェクト設定が最優先されます。
現在有効な設定を判断する最も確実な方法は、codex --helpログと組み合わせるか、明示的にcodex exec "show my current config"モデルに解釈させることです。
Profiles 名前付き設定レイヤー
Profileは Codex が推奨する「シナリオ別切り替え」の方法です。一連の設定を TOML ファイルとして保存し、必要に応じて--profileで読み込みます。
Profile ファイルは~/.codex/<name>.config.tomlにあります。ここで<name>は英数字、ハイフン、アンダースコアのみを含めることができます。
Profile を作成して使用する
たとえば、頻繁に深いコードレビューを行い、より強力な推論能力を使いたい場合：
例
model = "gpt-5.5" # 推論能力がより強いモデルを使用
model_reasoning_effort = "xhigh" # 推論強度を最大にする
approval_policy = "on-request" # ツール呼び出しのたびに承認を求める
model_catalog_json = "/Users/me/.codex/model-catalogs/deep-review.json" # オプション：カスタムモデルディレクトリ
Profile を使用して Codex を起動：
例
codex --profile deep-review
# または非対話型 exec モードで使用
codex exec --profile deep-review "review this change"
Profile のマージ（統合）セマンティクス
Profile ファイルは完全な設定ではありません。ユーザーレベルの~/.codex/config.tomlの上に重ねる差分上書きレイヤーです。
つまり、Profile には「デフォルト設定と異なる」フィールドだけを書けばよく、他のフィールドは自動的にユーザーレベル設定を継承します。
ユーザーレベルと Profile の両方でmodel_catalog_json，が設定されている場合、Profile の値が優先されます。。
Codex 0.134.0 以降、--profileはconfig.toml内の[profiles.<name>]テーブルを読み取らず、トップレベルのprofile = "name"セレクターもサポートされません。過去の Profile 設定はすべて独立した~/.codex/<name>.config.tomlファイルに移行する必要があります。
旧設定から Profile への移行
以前のconfig.tomlが次のような場合：
例
profile = "deep-review"
[profiles.deep-review]
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
2 つのファイルに分割する必要があります：
# 文件路径：~/.codex/config.toml（保留非 profile 部分） # 注意：删除了 profile = "deep-review" 选择器
# 文件路径：~/.codex/deep-review.config.toml model = "gpt-5.5" model_reasoning_effort = "xhigh"
移行後、従来のcodex --profile deep-reviewコマンドラインの使用方法は変わりません。
コマンドラインでの一時的なオーバーライド
一時的に 1、2 個のフィールドだけ変更してタスクを 1 回実行したい場合、設定ファイルを汚したくないことがあります。その場合は CLI で上書きできます：
専用フラグを優先して使用する
公式が専用パラメータを提供している場合（例：--model），専用フラグを優先して使用します。読みやすさが最も良いためです：
例
codex --model gpt-5.4
--config を使用して任意のキーを上書きする
専用フラグがないフィールドには、-c 或 --configで上書きします。値は TOML 形式であり、JSON ではありません。
例
codex --config model='"gpt-5.4"'
# ブール値はそのまま記述する
codex --config sandbox_workspace_write.network_access=true
# 配列は TOML 配列構文を使用する
codex --config 'shell_environment_policy.include_only=["PATH","HOME"]'
陥りやすい注意点のルール：
- ドット構文でネストしたフィールドを指定する。例：mcp_servers.context7.enabled=false
- --configの値は TOML として解析される。スペースを含む文字列は必ず引用符で囲むこと
- 解析に失敗した場合、Codex は値全体を文字列として扱う
オーバーライドが有効かどうかを確認する最速の方法は、コマンドの後に簡単な質問「what model are you using?」を続けて、Codex に現在の設定を能動的に報告させることです。
設定ファイルと状態の場所
Codex はすべてのローカル状態をCODEX_HOMEディレクトリに置く。デフォルトは~/.codex。
一般的なファイルとその意味：
| ファイル | 役割 | 機密性 |
|---|---|---|
| config.toml | ローカルメイン設定。すべてのカスタム項目はここに記述する | 否 |
| auth.json | ファイル形式の認証情報（システムキーチェーンを使用しない場合） | はい、600 権限を推奨 |
| history.jsonl | セッション履歴（無効化可能） | 機密内容を含む可能性あり |
| logs/、caches/ | 実行ログとキャッシュ | リクエストボディの断片を含む可能性あり |
OpenAI ベース URL だけを変更したい場合？
LLM プロキシ、ルーター、データ常駐プロジェクトを利用している多くのユーザーは、変更が必要なのはopenai組み込みプロバイダーの base URL のみです。
この場合は直接openai_base_urlを設定し、新規に[model_providers.openai]を作成しないでください。組み込み ID は上書きできないためです：
例
# 組み込みの openai プロバイダーの base URL をプロキシに向ける
openai_base_url = "https://us.api.openai.com/v1"
プロジェクトレベル設定 .codex/config.toml
プロジェクトレベル設定はリポジトリルートの.codex/config.tomlに配置し、チームでデフォルト値を共有するために使用します。
Codex は作業ディレクトリから上に向かって階層的に検索し、現在の作業ディレクトリに最も近いファイルの優先度が最高になります。
プロジェクトレベル設定の境界
セキュリティ上の理由から、プロジェクトが「信頼済み」とマークされている場合にのみプロジェクトレベルの .codex/ 層（config.toml、ローカル hooks、ローカル rules を含む）が読み込まれます。
信頼されていないプロジェクトでは、下記の表の機密キーは無視され、起動時に警告が出力されます：
| 無視されるキー | 理由 |
|---|---|
| openai_base_url、chatgpt_base_url | 認証情報のリダイレクト / host メタデータの変更を防止 |
| apps_mcp_product_sku | Codex Apps の製品識別に影響 |
| model_provider、model_providers | 認証情報 / プロバイダー ID の置き換えを防止 |
| notify | 任意のマシンローカルコマンドの実行を防止 |
| profile、profiles | プロジェクトレベルでは config profile を選択できない |
| experimental_realtime_ws_base_url、otel | テレメトリとリアルタイムチャネル |
これらのキーはユーザーレベルの~/.codex/config.tomlに配置する必要があります。
相対パス（例：model_instructions_file）は、その.codex/が置かれているディレクトリを基準に解決されます。
プロジェクトが信頼されておらず、model_provider = "proxy"を設定した場合、起動時に Codex は警告を出力し、デフォルトのプロバイダーを使用します。これはセキュリティ設計であり、バグではありません。
Hooks ライフサイクルフック
Hooks を使用すると、ツール呼び出しやターン開始などの重要なポイントにカスタムスクリプトを挿入でき、監査、機密語フィルター、コミットチェックなどに適しています。
Hooks 設定は2つの形式をサポートしており、イベント構造は完全に同一です：
| 形式 | 場所 | 適したシナリオ |
|---|---|---|
| hooks.jsonファイル | config.toml と同じディレクトリ | JSON ツールチェーンに親和性が高く、再利用が容易 |
| インライン[[hooks.*]] 表 | config.toml 内 | すべての設定を一元管理 |
最も一般的な4つの読み込み場所：
- ~/.codex/hooks.json
- ~/.codex/config.toml
- <repo>/.codex/hooks.json
- <repo>/.codex/config.toml
プロジェクトレベルの hooks はプロジェクトが信頼されている場合にのみ読み込まれ、ユーザーレベルの hooks は常に独立して読み込まれます。
インライン TOML Hook の例
以下は Bash ツール呼び出しの前に実行される事前チェックフックです：
例
# すべての Bash ツール呼び出しにマッチ
[[hooks.PreToolUse]]
matcher = "^Bash$"
[[hooks.PreToolUse.hooks]]
type = "command"
# リポジトリ内の事前チェックスクリプトを呼び出す（パスは .codex/ が置かれているディレクトリを基準とする）
command = '/usr/bin/python3 "$(git rev-parse --show-toplevel)/.codex/hooks/pre_tool_use_policy.py"'
timeout = 30 # タイムアウト秒数。タイムアウト後は拒否とみなす
statusMessage = "Checking Bash command" # ステータスバー通知
同じ層にhooks.jsonとインラインの[hooks]テーブルの両方が存在する場合、Codex は両方を読み込んで警告を出力します。各層ではどちらか一方の形式のみを選択することを推奨します。メンテナンスコストが2倍になるのを防ぐためです。
カスタムモデルプロバイダー
Codex を LLM プロキシ、Ollama、Mistral、Azure などの非 OpenAI 公式エンドポイントに接続する必要がある場合、model_providersが入り口です。
組み込みプロバイダー ID（openai、ollama、lmstudio）は再利用できません。競合が発生するためです。
基本定義
例
model = "gpt-5.4" # モデル名は選択したプロバイダーによって決まる
model_provider = "proxy" # 下記の [model_providers.proxy] を指す
[model_providers.proxy]
name = "OpenAI using LLM proxy" # 表示名
base_url = "http://proxy.example.com"
env_key = "OPENAI_API_KEY" # 環境変数からキーを読み取る
[model_providers.local_ollama]
name = "Ollama"
base_url = "http://localhost:11434/v1"
[model_providers.mistral]
name = "Mistral"
base_url = "https://api.mistral.ai/v1"
env_key = "MISTRAL_API_KEY"
HTTP ヘッダーを追加する
一部のプロキシは追加のヘッダー（テナント識別子、機能フラグなど）を必要とします：
例
# 静的ヘッダー：毎回のリクエストに含める
http_headers = { "X-Example-Header" = "example-value" }
# 動的ヘッダー：値は環境変数から読み取る
env_http_headers = { "X-Example-Features" = "EXAMPLE_FEATURES" }
コマンドベース認証（Command-backed Auth）
プロバイダーの bearer token を外部の認証情報ヘルパーから動的に取得する必要がある場合は、[model_providers.<id>.auth]：
例
name = "OpenAI using LLM proxy"
base_url = "https://proxy.example.com/v1"
wire_api = "responses" インスタンス
[model_providers.proxy.auth]
command = "/usr/local/bin/fetch-codex-token"
args = ["--audience", "codex"]
timeout_ms = 5000 # Responses API プロトコルを使用
refresh_interval_ms = 300000 # 単回取得のタイムアウト
# 能動的更新サイクル（5分）
- auth コマンドの実行制約：stdinを受け取らず、token をstdout
- に出力する必要があります
- Codex は前後の空白を自動的にトリムし、空の token はエラーとみなしますrefresh_interval_ms = 0設定
- は認証失敗後にのみ更新することを意味します
Amazon Bedrock 組み込みプロバイダー
Amazon Bedrock 組み込みプロバイダーamazon-bedrockCodex にはmodel_provider組み込みプロバイダーが付属しており、
例
model_provider = "amazon-bedrock"
model = "<bedrock-model-id>"
[model_providers.amazon-bedrock.aws]
profile = "default" # ファイルパス：~/.codex/config.toml
region = "eu-central-1" # AWS プロファイル。未設定の場合は標準の認証情報チェーンを使用
# Bedrock リージョン.awsBedrock 組み込みプロバイダーはネストしたmodel_providers.<id>配下の profile と region の上書きのみをサポートします。その他のカスタム項目は標準の
OSS ローカルモード
OSS ローカルモード--ossCodex はローカルの「オープンソース」モデル（Ollama、LM Studio など）への接続をサポートしており、
を介して起動します。--ossプロバイダーを指定せずにoss_providerだけを渡した場合、Codex は
例
# ファイルパス：~/.codex/config.toml
oss_provider = "ollama"
# デフォルトのローカルプロバイダー。ollama または lmstudio を選択可能
例
codex --oss
# デフォルトの oss_provider（ollama）を使用
codex --oss --oss-provider lmstudio
Azure プロバイダーと微調整（ファインチューニング）
Azure プロバイダーとファインチューニング
例
[model_providers.azure]
name = "Azure"
base_url = "https://YOUR_PROJECT_NAME.openai.azure.com/openai"
env_key = "AZURE_OPENAI_API_KEY" # ファイルパス：~/.codex/config.toml
query_params = { api-version = "2025-04-01-preview" }
wire_api = "responses" # 環境変数からキーを読み取る
request_max_retries = 4 # Responses API プロトコルを使用
stream_max_retries = 10 # 通常リクエストのリトライ回数
stream_idle_timeout_ms = 300000 # ストリーミングリクエストのリトライ回数
# ストリーミングのアイドルタイムアウト（5分）openai組み込みopenai_base_urlプロバイダーの base URL を変更する必要がある場合は、[model_providers.openai]。
ChatGPT データ常駐プロジェクト
データ常駐（Data Residency）を有効にした ChatGPT プロジェクトでは、リージョンプレフィックス付きのベース URL を使用する必要があります：
例
model_provider = "openaidr"
[model_providers.openaidr]
name = "OpenAI Data Residency"
# "us" をデータ常駐ドキュメントで要求されるプレフィックス（eu、jp など）に置き換えます
base_url = "https://us.api.openai.com/v1"
すべてのモデルがデータ常駐に対応しているわけではありません。選択前に OpenAI データ常駐ドキュメントの「eligible models」リストを確認してください。
モデルの推論、詳細度、コンテキスト
モデルの動作を制御する最も一般的な4点セット：
例
model_reasoning_summary = "none" # 推論サマリーを無効化
model_verbosity = "low" # 回答の長さを短縮
model_supports_reasoning_summaries = true # モデルに推論の出力を強制
model_context_window = 128000 # コンテキストウィンドウサイズを上書き
そのうちmodel_verbosityResponses API を使用するプロバイダーでのみ有効で、Chat Completions プロバイダーはこの設定を無視します。
承認ポリシーとサンドボックスモード
approval_policyCodex がいつ停止して人間の確認を求めるかを制御し、sandbox_modeアクセスできるファイルとネットワークを制御します。
2つの次元は独立して組み合わせられます。以下は典型的な設定例です：
例
approval_policy = "untrusted" # その他のオプション：on-request、never、または { granular = { ... } }
approvals_reviewer = "user" # "auto_review" は自動レビューを使用
sandbox_mode = "workspace-write"
allow_login_shell = false # ログインシェルを無効化（セキュリティ強化項目）
# きめ細かい承認ポリシーの例（プロンプトカテゴリ別）
# approval_policy = { granular = {
# sandbox_approval = true,
# rules = true,
# mcp_elicitations = true,
# request_permissions = false, # 権限リクエスト系は直接 fail-closed
# skill_approval = false # skill スクリプト系は直接 fail-closed
# } }
[sandbox_workspace_write]
exclude_tmpdir_env_var = false # $TMPDIR への書き込みを許可
exclude_slash_tmp = false # /tmp への書き込みを許可
writable_roots = ["/Users/YOU/.pyenv/shims"] # 追加の書き込み可能ディレクトリ
network_access = false # デフォルトで外部ネットワークを禁止
[auto_review]
policy = """
Use your organization's automatic review policy.
"""
]
よくある組み合わせ早見表
| シナリオ | approval_policy | sandbox_mode | 説明 |
|---|---|---|---|
| ローカルでの日常開発 | on-request | workspace-write | ツール呼び出しのたびに確認を求め、最も安全 |
| CI 自動化 | never | workspace-write | 人間の介入なし。サンドボックスでのテストが必要 |
| 完全に信頼できる環境 | never | danger-full-access | サンドボックスを無効化。隔離環境でのみ使用 |
| 監査が厳格なシナリオ | untrusted | workspace-write | すべての書き込み操作に再確認が必要 |
サンドボックスを無効にする（注意して使用）
環境自体がすでにプロセスレベルの分離を行っている場合は、Codex サンドボックスを無効化できます：
例
sandbox_mode = "danger-full-access"
にworkspace-writeモードでは、一部の環境が.git/と.codex/読み取り専用を維持します。つまりgit commitなどのコマンドをサンドボックス外で実行する場合、承認が必要です。サンドボックス内で直接コミットするには、次を使用してください：rules明示的に許可してください。
Shell 環境変数戦略
shell_environment_policyCodex が子プロセスを起動する際に渡す環境変数を制御します。デフォルトの目標「シークレットの漏洩を減らす + タスクに必要なパスを保持する」です。
例
[shell_environment_policy]
inherit = "none" # クリーンな状態から開始（推奨）
set = { PATH = "/usr/bin", MY_FLAG = "1" } # 変数を明示的に設定
ignore_default_excludes = false # デフォルトの KEY/SECRET/TOKEN フィルタリングを保持
exclude = ["AWS_*", "AZURE_*"] # さらに glob に一致する変数を除外
include_only = ["PATH", "HOME"] # ホワイトリストのみを渡す（exclude を上書き）
パターン構文：大文字小文字を区別しない glob、*任意の文字列にマッチ、?単一文字にマッチ、[A-Z]は文字クラスです。
ignore_default_excludes = falseCodex 組み込みの KEY/SECRET/TOKEN フィルターは保持され、include/exclude より前に有効になります。
MCP サーバー
MCP（Model Context Protocol）サーバーにより、Codex を外部ツールセットに接続できます。
完全な MCP 設定の説明は公式MCP ドキュメントを参照してください。本記事では詳しく説明しません。一般的なパターン：
例
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
enabled = true
# --config を使用して特定の MCP サービスを一時的に無効化
# codex --config mcp_servers.context7.enabled=false
可観測性とテレメトリー（OTel）
Codex は OpenTelemetry による実行ログのエクスポートをサポートしていますが、デフォルトでは無効です。有効にする方法：
例
[otel]
environment = "staging" # デフォルトは dev
exporter = "none" # オプション: otlp-http または otlp-grpc
log_user_prompt = false # ユーザープロンプトの内容をエクスポートしない（推奨）
HTTP エクスポーターを選択
例
exporter = { otlp-http = {
endpoint = "https://otel.example.com/v1/logs",
protocol = "binary",
headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
}}
gRPC エクスポーターを選択
例
exporter = { otlp-grpc = {
endpoint = "https://otel.example.com:4317",
headers = { "x-otlp-meta" = "abc123" }
}}
エクスポートするイベントタイプ
Codex は構造化イベントを発行します。これには以下が含まれますが、これに限定されません：
| イベント | 意味 |
|---|---|
| codex.conversation_starts | モデル、推論設定、サンドボックス/承認ポリシー |
| codex.api_request | API リクエストの試行、ステータス、所要時間、エラー |
| codex.sse_event | SSE ストリームイベント、トークン数（response.completed 時） |
| codex.websocket_request、codex.websocket_event | WebSocket リクエストとメッセージ |
| codex.user_prompt | ユーザープロンプトの長さ。内容はデフォルトで redact |
| codex.tool_decision | ツール呼び出しの決定：承認/拒否、ソースが設定かユーザーか |
| codex.tool_result | ツール実行の所要時間、成功したかどうか、出力スニペット |
当 exporter = "none"その場合、Codex はイベントをメモリ内に記録しますが送信しません。無効にしても、イベントごとに非同期バッチがトリガーされ、プロセス終了時に flush されます。
匿名メトリクス（デフォルトで有効）
Codex はデフォルトで、少量の匿名使用状況とヘルスデータを定期的に送信し、異常を検出します。PII は含まれません。
完全に無効にする場合：
例
[analytics]
enabled = false
推論イベントの非表示と表示
CI ログでは、推論出力がしばしば「ノイズ」になるため、グローバルに無効化できます：
例
hide_agent_reasoning = true
逆に、モデルの生の推論内容を確認する必要がある場合：
例
show_raw_agent_reasoning = true
ワークフローが生の推論の公開を許可していることを確認した場合にのみ有効にしてください。一部のモデル（例：gpt-oss）は生の推論を出力しないため、この設定は効果がありません。
外部通知（notify）
Codex が1ターンを完了すると、外部スクリプトをトリガーして、デスクトップ通知、チャット webhook、CI ステータス更新などを実現できます。
例
notify = ["python3", "/path/to/notify.py"]
スクリプトは1つの JSON 引数を受け取ります。一般的なフィールド：
| フィールド | 意味 |
|---|---|
| type | 現時点ではagent-turn-complete |
| thread-id | セッション ID |
| turn-id | ターン ID |
| cwd | 作業ディレクトリ |
| input-messages | ユーザーメッセージのリスト |
| last-assistant-message | 最後の assistant メッセージ |
terminal-notifier を呼び出す簡単なスクリプト例：
例
#!/usr/bin/env python3
import json, subprocess, sys
def main() -> int:
notification = json.loads(sys.argv[1])
# ターン完了イベントのみ処理
if notification.get("type") != "agent-turn-complete":
return 0
title = f"Codex: {notification.get('last-assistant-message', 'Turn Complete!')}"
message = " ".join(notification.get("input-messages", []))
subprocess.check_output([
"terminal-notifier",
"-title", title,
"-message", message,
"-group", "codex-" + notification.get("thread-id", ""),
"-activate", "com.googlecode.iterm2",
])
return 0
if __name__ == "__main__":
sys.exit(main())
notify と tui.notifications の違い
| メカニズム | 適したシナリオ | 主要な設定 |
|---|---|---|
| notify | webhook、デスクトップ通知、CI フック | 外部プログラム |
| tui.notifications | TUI 組み込み通知 | イベントタイプによるフィルタリングをサポート |
| tui.notification_method | 端末通知方式 | auto / osc9 / bel |
| tui.notification_condition | トリガー条件 | unfocused / always |
autoモードでは、Codex は OSC 9 ターミナルエスケープシーケンスを優先的に使用します。一部の端末ではこれをデスクトップ通知として扱います。サポートされていない場合は BEL（\x07）。
フィードバックと履歴
フィードバック収集を無効にする
デフォルトでは、Codex は TUI で/feedbackコマンドを提供します。無効にする場合：
例
[feedback]
enabled = false
無効にした後/feedback無効メッセージが表示され、Codex はフィードバックの送信を拒否します。
履歴（history.jsonl）
Codex はデフォルトでローカルセッションのトランスクリプトを~/.codex/history.jsonlに書き込みます。無効にする方法：
例
[history]
persistence = "none"
ファイルサイズを制限（超過時は最も古いエントリを破棄して圧縮）：
例
[history]
max_bytes = 104857600 # 100 MiB
クリック可能な引用（Clickable Citations）
端末またはエディタがサポートしている場合、Codex はファイル参照をクリック可能なリンクとしてレンダリングできます。
例
# オプション：vscode、cursor、windsurf、vscode-insiders、none
file_opener = "vscode"
設定すると、参照は/home/サンプル/project/main.py:42に書き換えられvscode://file/.../main.py:42、VS Code でクリックするとジャンプできます。
プロジェクト指示の発見（AGENTS.md）
Codex が読み取るのはAGENTS.md（および関連ファイル）で、プロジェクトの規約をセッションの「最初のターン」に自動的に持ち込みます。
2つの主要な設定項目：
| 設定キー | 用途 | 典型値 |
|---|---|---|
| project_doc_max_bytes | 各 AGENTS.md から読み取る最大バイト数 | デフォルトで約 32 KiB |
| project_doc_fallback_filenames | AGENTS.md がない場合の代替ファイル名 | 如 CLAUDE.md |
ターミナルインターフェース（TUI）オプション
実行codexサブコマンドなしで実行すると、対話型 TUI に入ります。[tui]表の下にある一般的なキー：
| 键 | 用途 | 選択可能な値 |
|---|---|---|
| tui.notifications | TUI 通知の有効化/無効化。イベントタイプでフィルタリング可能 | ブール値 / イベントタイプ配列 |
| tui.notification_method | 端末通知方式 | auto、osc9、bel |
| tui.notification_condition | トリガー条件 | unfocused、always |
| tui.animations | ASCII アニメーションと shimmer エフェクト | true / false |
| tui.alternate_screen | 代替スクリーンを使用するかどうか（never に設定するとスクロール履歴を保持） | auto、always、never |
| tui.show_tooltips | ウェルカムページに初心者向けヒントを表示するかどうか | true / false |
よく使う設定の早見表
このセクションを「忘れたら見返す」早見チェックリストとしてお使いください：
| ニーズ | 設定場所 / コマンド |
|---|---|
| モデルの切り替え | --model gpt-5.4 或 model = "..." |
| シナリオ別の設定 | --profile <name> + ~/.codex/<name>.config.toml |
| 任意のフィールドを一時的に変更 | --config key=value（TOML 構文） |
| OpenAI エンドポイントの変更 | openai_base_url |
| プロキシ/独自構築ベンダーへの接続 | [model_providers.<id>] + model_provider |
| ローカルマシンの Ollama | --oss + oss_provider |
| サンドボックスの無効化（注意して使用） | sandbox_mode = "danger-full-access" |
| 匿名メトリクスの無効化 | [analytics] enabled = false |
| 履歴の無効化 | [history] persistence = "none" |
| フィードバックの無効化 | [feedback] enabled = false |
| デスクトップ通知 | notify = ["python3", "/path/to/notify.py"] |
よくある質問
プロジェクトレベル設定で設定した model_provider が反映されない？
セキュリティ上の理由から、model_provider、model_providers、profile、notifyなどの機密キーはプロジェクトレベルの .codex/config.toml では無視され、起動時に警告が出力されます。
これらのキーをユーザーレベル~/.codex/config.tomlの設定に移動すればOKです。
--config を書いても変化がない？
3点を確認してください：値が TOML 構文に適合しているか（配列は[]、文字列は""、ネストはドットを使用）；シェルがスペースを区切り文字として複数の値に分割していないか；キー名が正しく綴られているか。確認するには~/.codex/logs/の下の最新ログを開くと、解析に失敗した元の文字列を確認できます。
Profile 起動後もデフォルトモデルのまま？
最も一般的な原因：Profile ファイルがまだ古い[profiles.<name>]テーブルを使用しているか、ファイル名の接尾辞が.config.tomlではないことです。0.134.0 以降は~/.codex/<name>.config.toml形式のみ認識されます。
サンドボックスを無効にしても git commit に承認が必要？
無効化sandbox_modeは承認ポリシーに影響しません。git commitなどのコマンドは依然としてapproval_policy = "on-request"が原因でプロンプトが表示される可能性があります。「全自動コミット」を実現したい場合は、承認ポリシーも同時に設定する必要があります。never。
カスタムモデルで gpt-5 シリーズを選択できますか？
によりますbase_urlが指すサービスがサポートしているかどうか。Codex 自体はmodelフィールドを厳密に検証しないため、重要なのはプロバイダー側が認識して応答できるかどうかです。
その他の拡張