高度な設定¶

プロバイダー、ポリシー、インテグレーションをより細かく制御する必要がある場合は、これらのオプションを使用します。クイックスタートについては、設定の基本を参照してください。

プロジェクトガイダンス、再利用可能な機能、カスタムスラッシュコマンド、サブエージェントのワークフロー、インテグレーションの背景については、カスタマイズを参照してください。設定キーについては、設定リファレンスを参照してください。

プロファイル¶

プロファイルを使用すると、名前付きの設定レイヤーを保存し、CLI から切り替えられます。--profile profile-name を渡すと、Codex は ~/.codex/config.toml を読み込み、その上に ~/.codex/profile-name.config.toml を適用します。プロファイル名には、英字、数字、ハイフン、アンダースコアを使用できます。

プロファイルごとに個別の TOML ファイルを作成します。プロファイルファイルではトップレベルの設定キーを使用し、[profiles.profile-name] の下にネストしないでください。

# ~/.codex/deep-review.config.toml
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
approval_policy = "on-request"
model_catalog_json = "/Users/me/.codex/model-catalogs/deep-review.json"

codex --profile deep-review
codex exec --profile deep-review "review this change"

プロファイルファイルは、ベースとなるユーザー設定より上位で、プロジェクト設定および CLI 設定より下位のレイヤーです。そのため、ベース設定と異なる値だけを記述する必要があります。プロファイルファイルでは model_catalog_json も上書きできます。両方のファイルで設定されている場合、Codex はプロファイルの値を使用します。

Codex 0.134.0 以降では、--profile は config.toml から [profiles.profile-name] を読み取らなくなり、トップレベルの profile = "profile-name" セレクターもサポートされなくなりました。従来のプロファイル設定を ~/.codex/profile-name.config.toml に移動し、config.toml から対応する [profiles.profile-name] テーブルと profile = "profile-name" セレクターを削除してください。

CLI からの一時的な上書き¶

~/.codex/config.toml を編集するだけでなく、CLI から単一の実行に対する設定を上書きすることもできます。

• 専用フラグが存在する場合は、それを優先します（例: --model）。
• 任意のキーを上書きする必要がある場合は、-c / --config を使用します。

例:

# Dedicated flag
codex --model gpt-5.4

# Generic key/value override (value is TOML, not JSON)
codex --config model='"gpt-5.4"'
codex --config sandbox_workspace_write.network_access=true
codex --config 'shell_environment_policy.include_only=["PATH","HOME"]'

注:

• キーにはドット記法を使用してネストされた値を設定できます（例: mcp_servers.context7.enabled=false）。
• --config の値は TOML として解析されます。判断に迷う場合は、シェルが空白で値を分割しないよう、値を引用符で囲んでください。
• 値を TOML として解析できない場合、Codex は文字列として扱います。

設定と状態の保存場所¶

Codex はローカル状態を CODEX_HOME（デフォルトでは ~/.codex）の下に保存します。

そこには、次のような一般的なファイルがあります。

• config.toml（ローカル設定）
• auth.json（ファイルベースの認証情報ストレージを使用している場合）、または OS のキーチェーン / キーリング
• history.jsonl（履歴の永続化が有効な場合）
• ログやキャッシュなど、その他のユーザー単位の状態

認証の詳細（認証情報の保存モードを含む）については、認証を参照してください。設定キーの完全な一覧については、設定リファレンスを参照してください。

リポジトリまたはシステムパスにチェックインされた共有デフォルト、ルール、スキルについては、チーム設定を参照してください。

組み込みの OpenAI プロバイダーを LLM プロキシ、ルーター、またはデータレジデンシーが有効なプロジェクトに接続するだけであれば、新しいプロバイダーを定義する代わりに config.toml の openai_base_url を設定します。これにより、個別の model_providers.<id> エントリを作成せずに、組み込みの openai プロバイダーのベース URL が変更されます。

openai_base_url = "https://us.api.openai.com/v1"

プロジェクト設定ファイル（.codex/config.toml）¶

ユーザー設定に加えて、Codex はリポジトリ内の .codex/config.toml ファイルからプロジェクトスコープの上書きを読み取ります。Codex はプロジェクトルートから現在の作業ディレクトリまで移動し、見つかったすべての .codex/config.toml を読み込みます。複数のファイルで同じキーが定義されている場合、現在の作業ディレクトリに最も近いファイルが優先されます。

セキュリティ上、Codex はプロジェクトが信頼されている場合にのみ、プロジェクトスコープの設定ファイルを読み込みます。プロジェクトが信頼されていない場合、Codex は .codex/ レイヤーを無視します。これには .codex/config.toml、プロジェクトローカルのフック、プロジェクトローカルのルールが含まれます。ユーザーおよびシステムのレイヤーは分離されたまま、引き続き読み込まれます。

プロジェクト設定内の相対パス（例: model_instructions_file）は、config.toml を含む .codex/ フォルダーを基準に解決されます。

プロジェクト設定ファイルでは、認証情報のリダイレクト、ホスト所有のアプリリクエストメタデータの変更、プロバイダー認証の変更、設定プロファイルの選択、マシンローカルの通知 / テレメトリコマンドの実行を行う設定を上書きできません。Codex は、プロジェクトローカルの .codex/config.toml にある次のキーを無視し、検出時に起動時の警告を表示します: openai_base_url、chatgpt_base_url、apps_mcp_product_sku、model_provider、model_providers、notify、profile、profiles、experimental_realtime_ws_base_url、otel。プロバイダー、通知、テレメトリのキーはユーザーレベルの ~/.codex/config.toml に設定し、--profile profile-name と ~/.codex/profile-name.config.toml で設定プロファイルを選択してください。

フック¶

Codex は、hooks.json ファイル、またはアクティブな設定レイヤーの隣にある config.toml ファイル内のインライン [hooks] テーブルから、ライフサイクルフックを読み込むこともできます。

実際には、最も便利な場所は次の 4 つです。

• ~/.codex/hooks.json
• ~/.codex/config.toml
• <repo>/.codex/hooks.json
• <repo>/.codex/config.toml

プロジェクトローカルのフックは、プロジェクト .codex/ レイヤーが信頼されている場合にのみ読み込まれます。ユーザーレベルのフックは、プロジェクトの信頼状態から独立しています。

インライン TOML フックは、hooks.json と同じイベント構造を使用します。

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = '/usr/bin/python3 "$(git rev-parse --show-toplevel)/.codex/hooks/pre_tool_use_policy.py"'
timeout = 30
statusMessage = "Checking Bash command"

1 つのレイヤーに hooks.json とインライン [hooks] の両方が含まれている場合、Codex は両方を読み込み、警告を表示します。レイヤーごとに 1 つの表現だけを使用することを推奨します。

現在のイベント一覧、入力フィールド、出力動作、制限については、フックを参照してください。

エージェントのロール（config.toml 内の [agents]）¶

サブエージェントのロール設定（config.toml 内の [agents]）については、サブエージェントを参照してください。

プロジェクトルートの検出¶

Codex は、作業ディレクトリから上方向にプロジェクトルートまで移動して、プロジェクト設定（例: .codex/ レイヤーや AGENTS.md）を検出します。

デフォルトでは、Codex は .git を含むディレクトリをプロジェクトルートとして扱います。この動作をカスタマイズするには、config.toml に project_root_markers を設定します。

# Treat a directory as the project root when it contains any of these markers.
project_root_markers = [".git", ".hg", ".sl"]

project_root_markers = [] を設定すると、親ディレクトリの検索をスキップし、現在の作業ディレクトリをプロジェクトルートとして扱います。

カスタムモデルプロバイダー¶

モデルプロバイダーは、Codex がモデルに接続する方法（ベース URL、ワイヤー API、認証、オプションの HTTP ヘッダー）を定義します。カスタムプロバイダーでは、予約済みの組み込みプロバイダー ID openai、ollama、lmstudio を再利用できません。

追加のプロバイダーを定義し、model_provider で指定します。

model = "gpt-5.4"
model_provider = "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"

必要に応じてリクエストヘッダーを追加します。

[model_providers.example]
http_headers = { "X-Example-Header" = "example-value" }
env_http_headers = { "X-Example-Features" = "EXAMPLE_FEATURES" }

プロバイダーが外部の認証情報ヘルパーからベアラートークンを取得する必要がある場合は、コマンドによる認証を使用します。

[model_providers.proxy]
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
refresh_interval_ms = 300000

認証コマンドには stdin が渡されず、トークンを標準出力に出力する必要があります。Codex は前後の空白を削除し、空のトークンをエラーとして扱い、refresh_interval_ms で事前に更新します。認証の再試行後にのみ更新するには、refresh_interval_ms = 0 を設定します。[model_providers.<id>.auth] を env_key、experimental_bearer_token、requires_openai_auth と組み合わせないでください。

Amazon Bedrock プロバイダー¶

Codex には組み込みの amazon-bedrock モデルプロバイダーが含まれています。model_provider として直接設定できます。カスタムプロバイダーとは異なり、この組み込みプロバイダーがサポートするのは、ネストされた AWS プロファイルとリージョンの上書きだけです。

model_provider = "amazon-bedrock"
model = "<bedrock-model-id>"

[model_providers.amazon-bedrock.aws]
profile = "default"
region = "eu-central-1"

profile を省略すると、Codex は標準の AWS 認証情報チェーンを使用します。リクエストを処理する、サポート対象の Bedrock リージョンを region に設定します。

完全なセットアップ手順、認証オプション、サポート対象モデル、機能の利用可否については、Amazon Bedrock で ChatGPT Work と Codex を使用するを参照してください。

OSS モード（ローカルプロバイダー）¶

--oss を渡すと、Codex は Ollama や LM Studio などのローカルの「オープンソース」プロバイダーに対して実行できます。単一の実行で使用するプロバイダーを --local-provider で選択するか、デフォルトとして oss_provider を設定します。どちらも設定されていない場合、インタラクティブ CLI は選択を求めます。codex exec はエラーで終了します。

# Default local provider used with `--oss`
oss_provider = "ollama" # or "lmstudio"

Azure プロバイダーとプロバイダーごとの調整¶

[model_providers.azure]
name = "Azure"
base_url = "https://YOUR_PROJECT_NAME.openai.azure.com/openai"
env_key = "AZURE_OPENAI_API_KEY"
query_params = { api-version = "2025-04-01-preview" }
wire_api = "responses"
request_max_retries = 4
stream_max_retries = 10
stream_idle_timeout_ms = 300000

組み込みの OpenAI プロバイダーのベース URL を変更するには、openai_base_url を使用します。組み込みプロバイダー ID は上書きできないため、[model_providers.openai] は作成しないでください。

データレジデンシーを使用する ChatGPT の顧客¶

データレジデンシーを有効にして作成されたプロジェクトでは、正しいプレフィックスを使用して base_url を更新するモデルプロバイダーを作成できます。

model_provider = "openaidr"
[model_providers.openaidr]
name = "OpenAI Data Residency"
base_url = "https://us.api.openai.com/v1" # Replace 'us' with domain prefix

モデルの推論、詳細度、制限¶

model_reasoning_summary = "none"          # Disable summaries
model_verbosity = "low"                   # Shorten responses
model_supports_reasoning_summaries = true # Force reasoning
model_context_window = 128000             # Context window size

model_verbosity は Responses API を使用するプロバイダーにのみ適用されます。Chat Completions プロバイダーはこの設定を無視します。

承認ポリシーとサンドボックスモード¶

承認の厳格さ（Codex が一時停止するタイミングに影響）とサンドボックスレベル（ファイル / ネットワークアクセスに影響）を選択します。

config.toml の編集時に留意すべき運用上の詳細については、サンドボックスと承認の一般的な組み合わせ、書き込み可能なルート内の保護されたパス、ネットワークアクセスを参照してください。

ファイルシステムとネットワークアクセスをまとめて設定するベータ版の権限プロファイルについては、権限を参照してください。

詳細な承認ポリシー（approval_policy = { granular = { ... } }）を使用して、個々のプロンプトカテゴリを許可または自動拒否することもできます。これは、一部のケースでは通常のインタラクティブ承認を使用しつつ、request_permissions やスキルスクリプトのプロンプトなど、その他のケースは自動的にフェイルクローズしたい場合に便利です。

approvals_reviewer = "auto_review" を設定すると、対象となるインタラクティブな承認リクエストを自動レビューに送ります。これはレビュアーを変更するものであり、サンドボックスの境界は変更しません。

ローカルレビューポリシーの指示には [auto_review].policy を使用します。管理対象の guardian_policy_config が優先されます。

approval_policy = "untrusted"   # Other options: on-request, never, or { granular = { ... } }
approvals_reviewer = "user"     # Or "auto_review" for automatic review
sandbox_mode = "workspace-write"
allow_login_shell = false       # Optional hardening: disallow login shells for shell tools

# Example granular approval policy:
# approval_policy = { granular = {
#   sandbox_approval = true,
#   rules = true,
#   mcp_elicitations = true,
#   request_permissions = false,
#   skill_approval = false
# } }

[sandbox_workspace_write]
exclude_tmpdir_env_var = false  # Allow $TMPDIR
exclude_slash_tmp = false       # Allow /tmp
writable_roots = ["/Users/YOU/.pyenv/shims"]
network_access = false          # Opt in to outbound network

[auto_review]
policy = """
Use your organization's automatic review policy.
"""

名前付き権限プロファイル¶

組み込みプロファイル、カスタムプロファイルの構文、ファイルシステムとネットワークの完全な設定モデルについては、権限を参照してください。

キーの完全な一覧と要件の制約については、設定リファレンスおよび管理対象設定を参照してください。

workspace-write モードでは、環境によっては、ワークスペースの残りの部分が書き込み可能であっても、.git/ と .codex/ が読み取り専用のままになることがあります。そのため、git commit のようなコマンドでも、サンドボックス外で実行する際に承認が必要になる場合があります。特定のコマンドをスキップしたい場合（たとえば、サンドボックス外での git commit をブロックする場合）は、rules を使用します。

サンドボックスを完全に無効にします（環境がすでにプロセスを分離している場合にのみ使用してください）。

sandbox_mode = "danger-full-access"

シェル環境ポリシー¶

shell_environment_policy は、Codex が起動するサブプロセス（モデルが提案したツールコマンドを実行する場合など）に渡す環境変数を制御します。クリーンな開始状態（inherit = "none"）または絞り込んだセット（inherit = "core"）から始め、除外、包含、上書きを重ねて、必要なパス、キー、フラグを提供しながら秘密情報の漏えいを防ぎます。

[shell_environment_policy]
inherit = "none"
set = { PATH = "/usr/bin", MY_FLAG = "1" }
ignore_default_excludes = false
exclude = ["AWS_*", "AZURE_*"]
include_only = ["PATH", "HOME"]

パターンは大文字と小文字を区別しない glob（*、?、[A-Z]）です。ignore_default_excludes = false により、包含 / 除外の処理前に自動的な KEY / SECRET / TOKEN フィルターが維持されます。

MCP サーバー¶

設定の詳細については、専用のMCP ドキュメントを参照してください。

可観測性とテレメトリ¶

OpenTelemetry（OTel）ログのエクスポートを有効にすると、Codex の実行（API リクエスト、SSE / イベント、プロンプト、ツールの承認 / 結果）を追跡できます。デフォルトでは無効です。[otel] でオプトインします。

[otel]
environment = "staging"   # defaults to "dev"
exporter = "none"         # set to otlp-http or otlp-grpc to send events
log_user_prompt = false   # redact user prompts unless explicitly enabled

エクスポーターを選択します。

[otel]
exporter = { otlp-http = {
  endpoint = "https://otel.example.com/v1/logs",
  protocol = "binary",
  headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
}}

[otel]
exporter = { otlp-grpc = {
  endpoint = "https://otel.example.com:4317",
  headers = { "x-otlp-meta" = "abc123" }
}}

exporter = "none" の場合、Codex はイベントを記録しますが、何も送信しません。エクスポーターは非同期でバッチ処理し、シャットダウン時にフラッシュします。イベントメタデータには、サービス名、CLI バージョン、環境タグ、会話 ID、モデル、サンドボックス / 承認設定、イベントごとのフィールドが含まれます（設定リファレンスを参照）。

出力される情報¶

Codex は、実行とツールの使用状況について構造化ログイベントを出力します。代表的なイベントタイプは次のとおりです。

• codex.conversation_starts（モデル、推論設定、サンドボックス / 承認ポリシー）
• codex.api_request（試行、ステータス / 成功、所要時間、エラーの詳細）
• codex.sse_event（ストリームイベントの種類、成功 / 失敗、所要時間、response.completed のトークン数）
• codex.websocket_request および codex.websocket_event（リクエスト時間、メッセージごとの種類 / 成功 / エラー）
• codex.user_prompt（長さ。明示的に有効にしない限り内容は編集されます）
• codex.tool_decision（承認 / 拒否、決定元が設定かユーザーか）
• codex.tool_result（所要時間、成功、出力スニペット）

出力される OTel メトリクス¶

OTel メトリクスパイプラインが有効な場合、Codex は API、ストリーム、ツールのアクティビティについてカウンターと所要時間のヒストグラムを出力します。

以下の各メトリクスには、デフォルトのメタデータタグ auth_mode、originator、session_source、model、app.version も含まれます。

テレメトリに関するセキュリティとプライバシーの詳しいガイダンスについては、セキュリティを参照してください。

メトリクス¶

デフォルトでは、Codex は匿名の使用状況および健全性データを少量、定期的に OpenAI に送信します。これは Codex が正しく動作していない状況の検出や、使用されている機能および設定オプションの把握に役立ち、Codex チームが重要な事項に集中できるようにします。これらのメトリクスには、個人を特定できる情報（PII）は含まれません。メトリクスの収集は、OTel のログ / トレースのエクスポートとは独立しています。

マシン上の ChatGPT デスクトップアプリ、Codex CLI、IDE 拡張機能全体でメトリクス収集を無効にするには、設定で分析フラグを設定します。

[analytics]
enabled = false

各メトリクスには、固有のフィールドに加えて、以下のデフォルトコンテキストフィールドが含まれます。

デフォルトコンテキストフィールド（すべてのイベント / メトリクスに適用）¶

• auth_mode: swic | api | unknown。
• model: 使用されたモデルの名前です。
• app.version: Codex のバージョンです。

メトリクスカタログ¶

各メトリクスには、必須フィールドと上記のデフォルトコンテキストフィールドが含まれます。以下のメトリクス名では、codex. プレフィックスを省略しています。ほとんどのメトリクス名は codex-rs/otel/src/metrics/names.rs に集約されています。このファイルの外部で出力される機能固有のメトリクスも、ここに含まれます。メトリクスに tool フィールドが含まれる場合、それは使用された内部ツール（例: apply_patch または shell）を示すものであり、codex が適用しようとしている実際のシェルコマンドやパッチは含まれません。

ランタイムとモデル転送¶

cloud_requirements.fetch_attempt メトリクスには trigger、attempt、outcome、status_code フィールドが含まれます。cloud_requirements.fetch_final メトリクスには trigger、outcome、reason、attempt_count、status_code フィールドが含まれます。

ターンとツールのアクティビティ¶

mcp.call と mcp.call.duration_ms のメトリクスには status が含まれます。通常のツール呼び出しの出力には tool も含まれ、利用可能な場合は connector_id と connector_name も含まれます。ブロックされた Codex Apps MCP 呼び出しでは、status のみを含む mcp.call が出力される場合があります。

スレッド、タスク、機能¶

shell_snapshot メトリクスには success が含まれ、失敗時には failure_reason も含まれます。

メモリとローカル状態¶

external_agent_config.detect と external_agent_config.import のメトリクスには migration_type が含まれます。スキルの移行には skills_count も含まれます。

Windows サンドボックス¶

昇格セットアップの失敗メトリクスには、Windows セットアップの失敗詳細が利用可能な場合、code と message が含まれます。また、共有セットアップパスから出力された場合は originator が含まれることがあります。windows_sandbox.legacy_setup_preflight_failed メトリクスには、共有セットアップパスから出力された場合に originator が含まれますが、フォールバックプロンプトの事前チェック失敗にはフィールドが含まれない場合があります。

フィードバック制御¶

デフォルトでは、ローカルクライアントはユーザーが /feedback からフィードバックを送信できるようにします。マシン上の ChatGPT デスクトップアプリ、Codex CLI、IDE 拡張機能全体でフィードバック収集を無効にするには、設定を更新します。

[feedback]
enabled = false

無効にすると、/feedback は無効化メッセージを表示し、Codex はフィードバックの送信を拒否します。

推論イベントの非表示または表示¶

「推論」出力が多すぎる場合（CI ログなど）は、抑制できます。

hide_agent_reasoning = true

モデルが出力する生の推論内容を表示したい場合は、次のようにします。

show_raw_agent_reasoning = true

ワークフロー上問題ない場合にのみ、生の推論を有効にしてください。gpt-oss など、一部のモデル / プロバイダーは生の推論を出力しません。その場合、この設定による目に見える効果はありません。

通知¶

notify を使用すると、Codex がサポート対象イベント（現在は agent-turn-complete のみ）を出力するたびに外部プログラムをトリガーできます。これは、デスクトップ通知、チャット Webhook、CI の更新、組み込み TUI 通知では対応できないサイドチャネルのアラートなどに便利です。

notify = ["python3", "/path/to/notify.py"]

agent-turn-complete に反応する notify.py の例（省略版）:

#!/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())

スクリプトは単一の JSON 引数を受け取ります。一般的なフィールドは次のとおりです。

• type（現在は agent-turn-complete）
• thread-id（セッション識別子）
• turn-id（ターン識別子）
• cwd（作業ディレクトリ）
• input-messages（ターンにつながったユーザーメッセージ）
• last-assistant-message（最後のアシスタントメッセージテキスト）

スクリプトをディスク上の任意の場所に配置し、notify でその場所を指定します。

notify と tui.notifications¶

• notify は外部プログラムを実行します（Webhook、デスクトップ通知、CI フックに適しています）。
• tui.notifications は TUI に組み込まれており、イベントタイプ（例: agent-turn-complete と approval-requested）で任意にフィルタリングできます。
• tui.notification_method は TUI が端末通知を出力する方法（auto、osc9、または bel）を制御します。
• tui.notification_condition は、端末が unfocused または always の場合にのみ TUI 通知を発生させるかどうかを制御します。

auto モードでは、Codex は OSC 9 通知（端末によってはデスクトップ通知として解釈される端末エスケープシーケンス）を優先し、それ以外の場合は BEL（\x07）にフォールバックします。

正確なキーについては、設定リファレンスを参照してください。

履歴の永続化¶

デフォルトでは、Codex はローカルセッションのトランスクリプトを CODEX_HOME（例: ~/.codex/history.jsonl）の下に保存します。ローカル履歴の永続化を無効にするには、次のようにします。

[history]
persistence = "none"

履歴ファイルのサイズ上限を設定するには、history.max_bytes を設定します。ファイルが上限を超えると、Codex は古いエントリを削除し、最新のレコードを保持したままファイルをコンパクト化します。

[history]
max_bytes = 104857600 # 100 MiB

クリック可能な引用¶

対応するターミナル / エディターインテグレーションを使用している場合、Codex はファイル引用をクリック可能なリンクとして表示できます。file_opener を設定して、Codex が使用する URI スキームを選択します。

file_opener = "vscode" # or cursor, windsurf, vscode-insiders, none

例: /home/user/project/main.py:42 のような引用を、クリック可能な vscode://file/...:42 リンクに書き換えられます。

プロジェクト指示の検出¶

Codex は AGENTS.md（および関連ファイル）を読み取り、セッションの最初のターンに限られた量のプロジェクトガイダンスを含めます。この動作は、次の 2 つの設定で制御します。

• project_doc_max_bytes: 各 AGENTS.md ファイルから読み取る量
• project_doc_fallback_filenames: ディレクトリレベルで AGENTS.md が見つからない場合に試す追加のファイル名

詳しい手順については、AGENTS.md を使用したカスタム指示を参照してください。

TUI オプション¶

codex をサブコマンドなしで実行すると、インタラクティブなターミナル UI（TUI）が起動します。Codex は [tui] の下に TUI 固有の設定をいくつか公開しています。これには次のものが含まれます。

• tui.notifications: 通知を有効化 / 無効化（または特定のタイプに制限）
• tui.notification_method: 端末通知に auto、osc9、または bel を選択
• tui.notification_condition: 通知を発生させるタイミングとして unfocused または always を選択
• tui.animations: ASCII アニメーションとシマー効果を有効化 / 無効化
• tui.alternate_screen: 代替画面の使用を制御（never に設定すると端末のスクロールバックを保持）
• tui.show_tooltips: ウェルカム画面のオンボーディングツールチップを表示 / 非表示

tui.notification_method のデフォルトは auto です。auto モードでは、端末が対応していると見られる場合、Codex は OSC 9 通知（端末によってはデスクトップ通知として解釈される端末エスケープシーケンス）を優先し、それ以外の場合は BEL（\x07）にフォールバックします。

キーの完全な一覧については、設定リファレンスを参照してください。