Расширенная конфигурация

Используйте эти параметры, когда требуется более точный контроль над поставщиками, политиками и интеграциями. Краткое руководство по началу работы см. в разделе Основы конфигурации.

Сведения об инструкциях для проектов, многократно используемых возможностях, пользовательских командах с косой чертой, рабочих процессах с субагентами и интеграциях см. в разделе Настройка. Ключи конфигурации описаны в Справочнике по конфигурации.

Профили

Профили позволяют сохранять именованные слои конфигурации и переключаться между ними из 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 больше не считывает [profiles.profile-name] из config.toml, а селектор верхнего уровня profile = "profile-name" больше не поддерживается. Перенесите устаревшие настройки профилей в ~/.codex/profile-name.config.toml, а затем удалите соответствующую таблицу [profiles.profile-name] и селектор profile = "profile-name" из config.toml.

Однократные переопределения из CLI

Помимо редактирования ~/.codex/config.toml, конфигурацию для одного запуска можно переопределить из CLI:

• Отдавайте предпочтение специализированным флагам, если они предусмотрены (например, --model).
• Используйте -c / --config, когда требуется переопределить произвольный ключ.

Примеры:

# Dedicated flag
codex --model gpt-5.6-terra

# Generic key/value override (value is TOML, not JSON)
codex --config model='"gpt-5.6-terra"'
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 (при использовании файлового хранилища учётных данных) либо связка ключей или хранилище ключей вашей ОС
• history.jsonl (если включено сохранение истории)
• Другое состояние пользователя, например журналы и кеши

Подробности аутентификации, включая режимы хранения учётных данных, см. в разделе Аутентификация. Полный список ключей конфигурации приведён в Справочнике по конфигурации.

Общие значения по умолчанию, правила и навыки, добавленные в репозитории или системные пути, описаны в разделе Командная конфигурация.

Если требуется лишь направить встроенного поставщика OpenAI на прокси-сервер LLM, маршрутизатор или проект с включённой локализацией данных, задайте openai_base_url в config.toml вместо определения нового поставщика. Это изменит базовый URL встроенного поставщика openai без необходимости создавать отдельную запись model_providers.<id>.

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) разрешаются относительно папки .codex/, содержащей config.toml.

Файлы конфигурации проекта не могут переопределять параметры, которые перенаправляют учётные данные, изменяют принадлежащие хосту метаданные запросов приложения, меняют аутентификацию поставщика, выбирают профили конфигурации или запускают локальные команды уведомлений или телеметрии. 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, либо из встроенных таблиц [hooks] в файлах config.toml, расположенных рядом с активными слоями конфигурации.

На практике наиболее полезны следующие четыре расположения:

• ~/.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"

Если один слой содержит одновременно hooks.json и встроенный [hooks], Codex загружает оба варианта и выводит предупреждение. Используйте только одно представление в каждом слое.

Актуальный список событий, входные поля, поведение выходных данных и ограничения см. в разделе Хуки.

Роли агентов ([agents] в config.toml)

Настройка ролей субагентов ([agents] в config.toml) описана в разделе Субагенты.

Определение корня проекта

Codex обнаруживает конфигурацию проекта (например, слои .codex/ и AGENTS.md), поднимаясь от рабочего каталога вверх, пока не достигнет корня проекта.

По умолчанию Codex считает корнем проекта каталог, содержащий .git. Чтобы изменить это поведение, задайте project_root_markers в config.toml:

# 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. Пользовательские поставщики не могут использовать зарезервированные идентификаторы встроенных поставщиков: openai, ollama и lmstudio.

Определите дополнительных поставщиков и укажите их в model_provider:

model = "gpt-5.6-terra"
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.proxy]
name = "OpenAI using LLM proxy"
base_url = "https://proxy.example.com/v1"
env_key = "OPENAI_API_KEY"
supports_standalone_web_search = true

Для пользовательских поставщиков параметр по умолчанию имеет значение false. Отдельный веб-поиск находится в разработке и по умолчанию отключён. Значение true для возможности поставщика не включает её автоматически: поставщик должен поддерживать совместимую конечную точку, а выбранные модель и среда выполнения — отдельный поиск. Настроенный режим web_search и управляемые ограничения поиска продолжают действовать.

При необходимости добавьте заголовки запросов:

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

Используйте аутентификацию на основе команды, если поставщику необходимо, чтобы Codex получал bearer-токены от внешнего вспомогательного средства управления учётными данными:

[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 и должна вывести токен в stdout. 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. Задайте region, указав поддерживаемый регион Bedrock, который должен обрабатывать запросы.

Полный процесс настройки, варианты аутентификации, поддерживаемые модели и доступность функций описаны в разделе Использование ChatGPT Work и Codex с Amazon Bedrock.

Режим OSS (локальные поставщики)

Codex может работать с локальным поставщиком с «открытым исходным кодом», например Ollama или LM Studio, если передать --oss. Выберите поставщика для одного запуска с помощью --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

Чтобы изменить базовый URL встроенного поставщика OpenAI, используйте openai_base_url; не создавайте [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.
"""

Именованные профили разрешений

Встроенные профили, синтаксис пользовательских профилей и полная модель настройки файловой системы и сети описаны в разделе Разрешения.

Полный список ключей и ограничения требований см. в разделах Справочник по конфигурации и Управляемая конфигурация.

Полностью отключите песочницу (используйте этот вариант, только если ваша среда уже изолирует процессы):

sandbox_mode = "danger-full-access"

Политика окружения оболочки

shell_environment_policy определяет, какие переменные окружения Codex передаёт запускаемым командам. Начните с пустого окружения с помощью inherit = "none" или унаследуйте сокращённый набор с помощью inherit = "core". Добавьте явные значения и фильтры по ключам, чтобы не передавать запускаемым командам лишние секреты.

[shell_environment_policy]
inherit = "core"
set = { MY_FLAG = "1" }
ignore_default_excludes = false

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

Шаблоны фильтров не учитывают регистр и поддерживают * и ?. Используйте "exclude" для удаления соответствующих переменных. Если какой-либо шаблон использует "include", Codex сохраняет только переменные, соответствующие шаблону включения. Включения не восстанавливают переменные, которые уже были исключены. Ключи фильтров объединяются без учёта регистра между слоями конфигурации.

По умолчанию ignore_default_excludes имеет значение true, поэтому Codex не удаляет автоматически имена переменных, содержащие KEY, SECRET или TOKEN. Задайте значение false, чтобы применить эти автоматические исключения до выполнения явных фильтров.

Сначала Codex применяет автоматические исключения, затем пользовательские исключения, значения из set и, наконец, список разрешённых шаблонов включения. Поскольку set обрабатывается после исключений, он может восстановить исключённую переменную. При этом список разрешённых шаблонов включения всё равно может удалить восстановленное значение.

Старые массивы exclude и include_only по-прежнему поддерживаются в существующих конфигурациях. Не сочетайте ни один из этих массивов с [shell_environment_policy.filters] в одном слое конфигурации: Codex отклоняет такое сочетание.

Серверы 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, тег среды, идентификатор диалога, модель, настройки песочницы и подтверждений, а также поля отдельных событий (см. Справочник по конфигурации).

Какие данные передаются

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. Заблокированные вызовы MCP для Codex Apps могут передавать mcp.call только с status.

Потоки, задачи и функции

Метрика shell_snapshot включает success, а при сбоях — failure_reason.

Память и локальное состояние

Метрики external_agent_config.detect и external_agent_config.import включают migration_type; миграции навыков также включают skills_count.

Песочница Windows

Метрики сбоев настройки с повышенными привилегиями включают code и message, когда доступны сведения о сбое настройки Windows, а также могут включать 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). Это удобно для уведомлений на рабочем столе, вебхуков чатов, обновлений CI и любых оповещений по дополнительным каналам, которые не охватывают встроенные уведомления TUI.

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

Пример notify.py (сокращенный), реагирующего на agent-turn-complete:

#!/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 запускает внешнюю программу (подходит для вебхуков, уведомлений на рабочем столе и хуков CI).
• tui.notifications встроен в TUI и может фильтровать уведомления по типу события (например, agent-turn-complete и approval-requested).
• tui.notification_method определяет, как TUI отправляет уведомления терминала (auto, osc9 или bel).
• tui.notification_condition определяет, отправляются ли уведомления TUI, только когда терминал находится в состоянии unfocused или always.

В режиме 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, чтобы выбрать схему URI, которую использует Codex:

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

Пример: ссылка в цитате вида /home/user/project/main.py:42 может быть преобразована в интерактивную ссылку vscode://file/...:42.

Обнаружение инструкций проекта

Codex читает AGENTS.md (и связанные файлы) и добавляет ограниченный объем инструкций проекта в первый ход сеанса. Это поведение регулируют два параметра:

• project_doc_max_bytes: объем данных, считываемых из каждого файла AGENTS.md
• project_doc_fallback_filenames: дополнительные имена файлов, которые следует проверять, если на уровне каталога отсутствует AGENTS.md

Подробное пошаговое описание приведено в разделе Пользовательские инструкции с AGENTS.md.

Настольное приложение

Параметры в этом разделе применяются только к приложению ChatGPT для настольных систем.

Добавление пользовательских обработчиков файлов

В пользовательском файле ~/.codex/config.toml добавьте записи в раздел desktop.custom_file_handlers, чтобы открывать файлы в редакторах или внутренних средствах запуска, которые приложение ChatGPT для настольных систем не поддерживает по умолчанию. Каждая запись добавляет целевой редактор в меню Открыть в приложения. Приложение отображает целевой вариант, если command является существующим абсолютным путем или разрешается через PATH приложения.

В следующем примере показаны три способа передачи файла обработчику:

# Append the opened path directly after the command.
[desktop.custom_file_handlers.vscodium]
label = "VSCodium"
icon = "/Users/you/.codex/icons/vscodium.png"
command = "codium"

# Place fixed arguments before the opened path.
[desktop.custom_file_handlers.textedit]
label = "TextEdit"
icon = "/Users/you/.codex/icons/textedit.png"
command = "/usr/bin/open"
args = ["-a", "TextEdit"]

# Append one JSON argument with the path and editor context.
[desktop.custom_file_handlers.company_editor]
label = "Company Editor"
icon = "/opt/company/editor/icon.png"
command = "/opt/company/bin/editor"
input = "json_argument"

Сохраните config.toml, затем перезапустите приложение ChatGPT для настольных систем.

Идентификатор обработчика — это последний сегмент заголовка таблицы TOML. Он должен содержать от 1 до 64 символов, начинаться с ASCII-буквы или цифры, а остальные символы могут быть только ASCII-буквами, цифрами, точками, символами подчеркивания или дефисами. Приложение предоставляет идентификатор с префиксом custom:; например, company_editor преобразуется в custom:company_editor. Заключайте идентификатор с точкой в кавычки, чтобы TOML не интерпретировал его как вложенную таблицу. Например:

[desktop.custom_file_handlers."company.editor"]
label = "Company Editor"
icon = "/opt/company/editor/icon.png"
command = "/opt/company/bin/editor"

Каждый обработчик поддерживает следующие поля:

Значение input определяет, что следует после args:

• path добавляет путь как последний аргумент команды.
• json_argument добавляет объект JSON с полями target, path, appPath и location. Значение location представляет собой объект со значениями line и column, отсчитываемыми с 1, или null.
• json_stdin записывает объект JSON в стандартный ввод вместо добавления аргумента. Он также включает hostConfig, remoteWorkspaceRoot и remotePath; эти поля имеют значение null, когда неприменимы.

Например, company_editor может получить следующий аргумент, когда пользователь открывает определенное место в исходном коде:

{
  "target": "custom:company_editor",
  "path": "/repo/src/index.ts",
  "appPath": null,
  "location": { "line": 12, "column": 3 }
}

Выбор пользовательского обработчика в качестве предпочтительного редактора сохраняется так же, как и выбор встроенного редактора, включая отдельные настройки для каждого проекта.

Параметры TUI

Запуск codex без подкоманды открывает интерактивный интерфейс терминала (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) в качестве резервного варианта.

Полный список ключей приведен в справочнике по конфигурации.