Разбор конфигурации config.toml: один файл для управления всеми параметрами
📚 Навигация по серии: Предыдущая статья 17 · Управление компьютером и браузером (Computer Use) дала Codex в руки новые возможности — он научился видеть экран, управлять рабочим столом и запускать браузер. В этой статье мы вернемся от графического интерфейса к простому текстовому файлу —
config.toml. Вы уже сталкивались с ним ранее (при настройке песочницы, активации памяти или выборе моделей). Теперь мы разберем его системно: где он находится, как выглядит, за что отвечает каждый параметр и как расставляются приоритеты при наложении нескольких конфигураций.
Говорят, что конфигурационный файл — это вещь из разряда «настроил и забыл», и пока работает, лучше его не трогать. Но в случае с Codex всё обстоит ровно наоборот.
Мой опыт был таким: когда я только начинал работать с Codex в марте 2026 года, я вообще не трогал config.toml. При каждом запуске я вручную переключал модели через /model, настраивал права с помощью /permissions и прописывал флаг --search для доступа к сети. За день эти рутинные действия приходилось повторять по 7–8 раз. В конце недели я посчитал: связку «мощная модель + права на запись в рабочей области» я вручную вводил не менее тридцати раз. И тут до меня дошло: я превратил действие, которое настраивается один раз и работает всегда, в бесконечное ручное повторение.
Ценность файла config.toml заключается именно в этом: это инструмент экономии времени для тех, кто не любит лишней рутины. Чем меньше вам хочется настраивать параметры при каждом запуске, тем больше причин уделить десять минут описанию этого файла.
Но важнее другое: здесь кроется ловушка, в которую часто попадают новички. Одни и те же настройки, прописанные в домашнем каталоге и внутри проекта, могут работать по-разному, а в проекте и вовсе проигнорироваться. В этой статье мы подробно разберем правила расположения файлов и приоритетов конфигурации, чтобы вы полностью понимали логику работы системы.
После прочтения этой статьи вы получите:
- Четкое понимание сути
config.tomlи его отличий отAGENTS.md(чтобы больше не путать их) - Знание о том, где располагаются, за что отвечают и как настраиваются пользовательский
~/.codex/config.tomlи проектный.codex/config.toml - Таблицу приоритетов наложения настроек и важную оговорку о безопасности для начинающих (некоторые параметры бесполезно прописывать внутри проектов)
- Описание семи-восьми ключевых параметров (
model,approval_policy,sandbox_mode,web_search,[features]...), которые вы будете менять чаще всего, и их настроек по умолчанию - Готовый шаблон минимальной конфигурации, команды временного переопределения параметров через
-cи переключения наборов настроек через--profile
01 Суть config.toml и отличия от AGENTS.md
Начнем с главного: config.toml — это пульт управления поведением Codex. Он использует формат TOML для контроля параметров моделей, согласования, песочницы, MCP и функциональных флагов. С файлом AGENTS.md они представляют собой разные сущности: один определяет «как работать», а второй — «что помнить».
Начинающие часто путают их между собой. Описание структуры проекта вы фиксируете в 11 · AGENTS.md, а настройки песочницы — в 15 · Права доступа, песочница и согласование. Первые относятся к AGENTS.md, а вторые — к config.toml, и содержат они принципиально разные данные.
Аналогия: инструкция по эксплуатации автомобиля vs физические кнопки на панели управления. Файл AGENTS.md похож на инструкцию по эксплуатации в бардачке: там простым языком (для Codex) написано «заправлять бензином АИ-95», «дать двигателю прогреться зимой». Агент считывает эти рекомендации при каждом запуске как справочную информацию. Файл config.toml — это физические кнопки управления на центральной консоли: температура кондиционера, обогрев сидений, режим вождения (Спорт или Эко). Это конкретные переключатели, обрабатываемые программно. Инструкция — это советы «словами», а панель управления — жестко заданное поведение.
TOML (Tom's Obvious Minimal Language) — это формат конфигурационного файла. Он прост для чтения и записи: на верхнем уровне задаются пары ключ = значение, разделы группируются через [название_таблицы]. Пример для ознакомления:
# ~/.codex/config.toml
model = "gpt-5.5"
approval_policy = "on-request"
sandbox_mode = "workspace-write"Официальное описание позиционирует его назначение кратко:
Codex stores user-level configuration at
~/.codex/config.toml.
На практике в файле config.toml вы будете настраивать следующие сценарии:
- «Хочу всегда использовать одну и ту же модель без ручного переключения» — параметр
model - «Хочу запускать сессии с правами записи в рабочей области и запросом подтверждения только при выходе за рамки» — параметры
sandbox_modeиapproval_policy - «Хочу использовать живой интернет-поиск вместо результатов из кэша» — параметр
web_search - «Хочу включить или отключить экспериментальную функцию» — раздел
[features]
Все эти параметры не являются советами для Codex, это программные переключатели его логики работы. В этом заключается их отличие от AGENTS.md.
💡 Резюме одной фразой:
AGENTS.md— это рекомендации на естественном языке, считываемые Codex, аconfig.toml— пульт программного управления поведением агента. Первый отвечает за фиксацию знаний, второй — за логику работы, не смешивайте их.
02 Где располагаются файлы: уровень пользователя и уровень проекта
Главное, что нужно понять о config.toml перед изучением ключей — этот файл может храниться в двух местах: в вашем домашнем каталоге (глобальные настройки) и внутри конкретного проекта (настройки только для этого проекта). Моя рутинная проблема в начале статьи возникла из-за путаницы между ними.
Аналогия: распределительный щит в прихожей vs выключатель в комнате. В доме есть главный электрощит (обычно в коридоре), задающий общие параметры по умолчанию (например, «ограничение мощности ночью»). Но в каждой комнате есть свои выключатели, которые управляют светом только в ней и имеют более высокий приоритет: если вы хотите включить яркую люстру в кабинете, вы нажимаете кнопку на стене кабинета, и это не влияет на другие комнаты. С config.toml ситуация аналогичная: глобальный файл в домашнем каталоге — это электрощит (для всех проектов), а файл проекта — комнатный выключатель (только для этой папки, переопределяющий общие настройки).
Пути расположения файлов приведены в таблице:
| Уровень | Расположение файла | На кого влияет | Что записывать | Обязательное условие |
|---|---|---|---|---|
| Пользователь (User) | ~/.codex/config.toml | На вас лично, охватывает все ваши проекты | Глобальные настройки: модель по умолчанию, уровень прав, MCP, уведомления | Нет |
| Проект (Project) | <repo>/.codex/config.toml | Только при работе в данном репозитории | Настройки проекта: используемая модель, уровень песочницы для папки | Проекту выражено доверие |
Здесь есть три важных момента:
Во-первых, глобальный путь в домашнем каталоге фиксирован: ~/.codex/config.toml. Папка ~/.codex (переменная окружения CODEX_HOME) используется для хранения служебных данных агента (настроек, сессий, логов, авторизаций). Если файла настроек в ней нет, создайте его вручную.
Во-вторых, настройки проекта сохраняются в подкаталог .codex/ в корне проекта (обратите внимание: имя папки начинается с точки, она скрыта в системе, ее имя совпадает с глобальной папкой настроек, но они находятся в разных местах). Настройки применяются только при работе внутри этого проекта.
В-третьих, локальный файл проекта загружается только в случае, если проекту выражено доверие. Это системная мера безопасности: она исключает выполнение скрытых деструктивных настроек из клонированных сторонних репозиториев. Официальная цитата:
If you mark a project as untrusted, Codex skips project-scoped
.codex/layers, including project-local config, hooks, and rules.
Таким образом: в репозитории без подтвержденного доверия локальный файл .codex/config.toml будет проигнорирован, применятся только общие настройки пользователя. Если локальные ключи не работают, проверьте статус доверия к проекту (он запрашивается при первом открытии каталога).
Практический выбор: куда прописывать настройки
При выборе места для настройки ответьте на один вопрос: «Этот параметр относится ко мне лично или к специфике конкретного проекта?»
- «Я хочу применять это везде» → Уровень пользователя (
~/.codex/config.toml). Примеры: «хочу использоватьgpt-5.5по умолчанию», «подключения серверов MCP», «скрипты уведомлений на рабочем столе». Настраивается один раз и работает во всех проектах. - «Это нужно только для этого проекта» → Уровень проекта (
<repo>/.codex/config.toml). Примеры: «этот старый проект требует определенной версии модели», «ограничить работу с кодом этого репозитория только режимом чтения». Эти настройки хранятся в репозитории, попадают в Git и распространяются на коллег (если они тоже подтвердили доверие к проекту).
Я использую простое правило: глобальный файл содержит мои личные предпочтения, файлы проектов я обычно оставляю пустыми. Исключение составляют репозитории со своей спецификой (например, проект заказчика, в котором мне разрешено только читать код). В такой папке я создаю локальный .codex/config.toml и прописываю одну строку sandbox_mode = "read-only". Это избавляет от ручной настройки прав при каждом запуске и страхует от переноса ограничений на другие проекты.
💡 Резюме одной фразой: глобальный файл пользователя
~/.codex/config.toml(находится в каталогеCODEX_HOME) управляет всеми сессиями; локальный файл проекта<repo>/.codex/config.tomlнастраивает конкретный репозиторий (загружается только при выражении доверия проекту).
03 Приоритеты конфигураций и важные ограничения безопасности
Одни и те же ключи можно прописать в обоих файлах. Возникает вопрос: если глобальный файл требует модель gpt-5.5, а локальный — другую, какой параметр применится? Для этого существует механизм приоритетов (precedence).
На самом деле уровней настройки больше двух: к файлам добавляются временные параметры командной строки, переключение профилей через --profile и системная конфигурация. Полная шкала приоритетов от высшего к низшему выглядит так:
| Приоритет | Источник | Суть простыми словами |
|---|---|---|
| 1 (высший) | Параметры CLI / --config | Временные ключи, переопределяющие параметры на одну сессию |
| 2 | Уровень проекта <repo>/.codex/config.toml | Настройки репозитория (при наличии доверия; от корня к текущей папке, ближайший переопределяет остальные) |
| 3 | Профиль, выбранный через --profile ~/.codex/<имя>.config.toml | Набор настроек с определенным именем |
| 4 | Уровень пользователя ~/.codex/config.toml | Глобальные настройки по умолчанию |
| 5 | Уровень системы /etc/codex/config.toml (в Unix, при наличии) | Задается администратором для всего компьютера |
| 6 (низший) | Встроенные значения по умолчанию | Параметры, зашитые в сам Codex на случай отсутствия файлов настроек |
Связи приоритетов показаны на схеме ниже. Каждый верхний слой переопределяет совпадающие ключи нижних слоев:
Схема показывает, что параметры верхнего уровня накладываются на нижние, поэтому приоритет всегда имеют более специфичные ключи командной строки и уровня проекта.
Запомните общее правило: более специфичный контекст переопределяет общий. Консоль переопределяет проект, проект — профиль, профиль — глобальный файл пользователя, он — системный файл, а тот — встроенные значения. Официальное руководство предлагает следующую тактику:
Use that precedence to set shared defaults in
config.tomland keep profile files focused on the values that differ.
Таким образом: глобальный файл содержит ваши типовые настройки, профили — точечные отличия для разных сценариев, а параметры командной строки служат для разовых запусков. Это дает ответ на вопрос из предыдущей статьи: для постоянного применения предпочтений настраивайте глобальный config.toml пользователя.
Важное ограничение: параметры, которые бесполезно писать в конфигурации проекта
Мы выяснили, что проект переопределяет общие настройки пользователя. Однако для некоторых ключей сделано исключение: если прописать их в локальном файле .codex/config.toml проекта, Codex проигнорирует их и выведет предупреждение при запуске. Это сделано в целях безопасности, и об этом правиле нужно знать.
Зачем нужна блокировка? Представьте, что скачанный из сети репозиторий содержит локальный .codex/config.toml, который перенаправляет ваши запросы к модели на сторонний сервер, меняет способ авторизации или запускает фоновые скрипты на вашей машине. Это критическая уязвимость. Поэтому параметры системного уровня безопасности разрешено прописывать исключительно в глобальном файле пользователя. Вот список этих ключей:
Codex ignores
openai_base_url,chatgpt_base_url,apps_mcp_product_sku,model_provider,model_providers,notify,profile,profiles,experimental_realtime_ws_base_url, andotelwhen they appear in a project-local.codex/config.toml.
Разберем назначение этих ключей:
| Параметр | Назначение | Почему только глобально |
|---|---|---|
model_provider / model_providers | Провайдеры моделей и URL серверов | Защита от перенаправления запросов на сторонние сервера |
openai_base_url / chatgpt_base_url | Базовые системные URL | То же самое — предотвращение подмены адресов отправки данных |
notify | Команды уведомлений после выполнения задач | Защита от автоматического запуска скрытых фоновых команд |
otel | Экспорт логов и телеметрии | Исключение передачи данных работы системы на неизвестные адреса |
profile / profiles | Активация наборов настроек | Выбор профиля осуществляется только пользователем через параметры запуска |
Запомните правило: адреса серверов моделей, скрипты уведомлений, телеметрия и выбор профилей настраиваются только в домашнем каталоге пользователя. В файле проекта разрешено прописывать только локальные параметры запуска вроде model, sandbox_mode или approval_policy. Если вы попытаетесь указать model_providers внутри папки проекта, система просто проигнорирует эту строку.
💡 Резюме одной фразой: приоритет наложения настроек идет по схеме: командная строка > уровень проекта > профиль > уровень пользователя. Однако параметры системной безопасности (
model_provider,notify,otel,profile) игнорируются в локальном файле проекта и могут быть заданы только глобально.
04 Ключевые параметры: назначение и настройки по умолчанию
Перейдем к описанию параметров, которые вам придется настраивать чаще всего. Спецификация config.toml содержит сотни ключей, но в обычной работе задействуется лишь малая их часть. Изучите их назначение и значения по умолчанию — это избавит вас от написания лишних строк:
| Параметр | Назначение | Значение по умолчанию | Пример записи |
|---|---|---|---|
model | Модель по умолчанию | Согласно системным настройкам | model = "gpt-5.5" |
approval_policy | Стратегия согласования | on-request | approval_policy = "on-request" |
sandbox_mode | Режим песочницы (доступ к ФС и сети) | workspace-write (для папок с Git) | sandbox_mode = "workspace-write" |
model_reasoning_effort | Глубина логических рассуждений | Согласно настройкам модели | model_reasoning_effort = "high" |
web_search | Режим интернет-поиска | cached (из кэша) | web_search = "live" |
personality | Стиль общения агента | friendly | personality = "pragmatic" |
file_opener | Редактор для открытия файлов по ссылкам | vscode | file_opener = "cursor" |
Примечание к значению sandbox_mode по умолчанию: при обычном запуске codex применяется режим Auto. В папках под управлением Git по умолчанию включается workspace-write (запись в рабочей области разрешена), в папках без Git — режим read-only (только чтение). Официально под «режимом песочницы по умолчанию» понимается поведение в репозиториях Git.
model / model_reasoning_effort / approval_policy / sandbox_mode
Эти четыре параметра наиболее важны. Мы детально разбирали их ранее: выбор моделей в главе 05, согласование и песочницу — в главе 15. Запомните: все они настраиваются в файле config.toml, избавляя вас от необходимости прописывать параметры /model или --sandbox при каждом запуске.
Параметр model_reasoning_effort задает глубину рассуждений модели. Доступны значения minimal | low | medium | high | xhigh (при поддержке моделью). Для простых задач выставляйте низкий уровень для экономии токенов и времени, для сложных архитектурных изменений — значение high.
web_search: интернет-поиск по умолчанию работает из кэша
Этот параметр работает отлично от интуитивных ожиданий. По умолчанию поиск включен, но использует режим cached — Codex обращается к сохраненной базе веб-страниц OpenAI, а не делает запросы к сайтам в реальном времени. Это снижает риски атак класса внедрения промптов (prompt injection) через динамические страницы.
Если вам нужны актуальные данные (например, свежая версия библиотеки), переопределите поведение:
web_search = "live" # Живой поиск в сети, эквивалентно флагу --search
# web_search = "cached" # По умолчанию: чтение из кэша
# web_search = "disabled" # Полное отключение интернет-поискаИсключение: при запуске полного доступа --yolo параметр web_search автоматически переключается в режим live.
personality: изменение стиля общения Codex
Ключ personality задает тон ответов агента. Доступны варианты none | friendly | pragmatic (дружелюбный / прагматичный). Его можно переключать и в сессии через /personality. Рекомендую использовать pragmatic — агент будет общаться без лишних вежливых фраз, сразу переходя к коду и выводам.
file_opener: открытие ссылок на файлы в редакторе
Codex часто выводит ссылки на файлы в формате file.py:42. Параметр file_opener определяет редактор, который откроет файл при клике. По умолчанию используется vscode, также поддерживаются vscode-insiders | windsurf | cursor | none. Если вы работаете в Cursor, укажите cursor — ссылки станут кликабельными и будут открывать файлы на нужной строке.
Важное правило TOML: глобальные ключи пишутся в начале файла
Это частая синтаксическая ошибка. По спецификации TOML все глобальные пары ключ = значение должны располагаться строго до объявления разделов (таблиц) [название_таблицы]. В комментариях к шаблону конфигурации на это обращается особое внимание:
Root keys must appear before tables in TOML.
Сравните корректный и некорректный варианты:
| ❌ Ошибка (глобальный ключ объявлен после таблицы) | ✅ Правильно (все глобальные ключи в начале файла) |
|---|---|
[features]hooks = truemodel = "gpt-5.5" ← Ошибка | model = "gpt-5.5"[features]hooks = true |
Правило: сначала прописываются простые глобальные параметры (model, approval_policy и т.д.), затем объявляются разделы [название_таблицы]. Ошибка структуры файла приведет к сбою парсинга TOML при запуске.
💡 Резюме одной фразой: ключевые параметры — это
model,approval_policy,sandbox_mode,model_reasoning_effort,web_search(по умолчанию кэшируется!),personalityиfile_opener. Если вас устраивают значения по умолчанию, не прописывайте их лишний раз. И главное: глобальные ключи объявляются до разделов в TOML.
05 Раздел [features]: управление экспериментальными функциями
Раздел [features] заслуживает отдельного описания — это пульт управления всеми экспериментальными и опциональными функциями Codex. Именно здесь включаются и выключаются механизмы памяти (Memory), хуки (hooks) и совместная работа субагентов.
Аналогия: меню разработчика или лаборатория функций в смартфоне. Базовые возможности системы активны изначально. Но в разделе «Лаборатория» собраны переключатели новых функций: они могут быть включены или выключены по умолчанию, и вы управляете ими вручную. Раздел [features] — это такая лаборатория Codex: каждая функция имеет логический флаг (true для включения, false для отключения).
Раздел объявляется через [features], ниже перечисляются ключи:
[features]
memories = true # Включить Память (Memory)
shell_snapshot = true # Активировать снимки консоли
hooks = false # Отключить выполнение хуковСписок ключевых переключателей, которые могут вам понадобиться:
| Параметр | По умолчанию | Статус | Назначение |
|---|---|---|---|
hooks | true | Стабильно | Хуки жизненного цикла (запуск скриптов по событиям) |
multi_agent | true | Стабильно | Совместная работа субагентов |
shell_snapshot | true | Стабильно | Снимки окружения консоли для ускорения частых команд |
fast_mode | true | Стабильно | Режим быстрого ответа (экономия времени ожидания) |
shell_tool | true | Стабильно | Встроенный терминал для запуска системных команд |
personality | true | Стабильно | Выбор тона общения агента |
memories | false | Стабильно | Память агента (Memories, разберем в следующей главе) |
codex_git_commit | false | Экспериментально | Автоматическая генерация описаний коммитов Git |
apps | false | Экспериментально | Поддержка ChatGPT Apps и интеграций |
undo | false | Стабильно | Поддержка отката изменений через снимки git ghost |
⚠️ Экспериментальные функции могут измениться. Параметры со статусом экспериментальных могут поменять поведение по умолчанию. Перед их изменением сверяйтесь с актуальной версией справочника Config Reference.
Частая ошибка: использование устаревшего синтаксиса (например, ключа codex_hooks = true в разделе [features]). Сейчас официальное название параметра — hooks, старое имя является устаревшим и не рекомендуется к использованию. Ориентируйтесь на новые имена ключей.
Три способа управления флагами:
- В файле
config.toml: указатьимя_функции = true(илиfalse) в разделе[features]; - В параметрах командной строки: использовать
--enable имя_функции(или несколько параметров по очереди); - Отключение: перевести флаг в значение
falseв конфигурации.
Мой совет: не активируйте все экспериментальные возможности сразу. Начните с памяти (memories = true), остальные флаги оставьте по умолчанию для стабильной работы.
💡 Резюме одной фразой: раздел
[features]управляет экспериментальными возможностями через флаги истинности. Параметрыhooks,multi_agentиshell_snapshotвключены изначально;memoriesиappsтребуют ручной активации. Временное включение флагов на одну сессию доступно через параметр запуска--enable. Используйте современные имена параметров.
06 Временное переопределение vs Использование профилей: параметры -c и --profile
Иногда статической конфигурации файла недостаточно: вам может потребоваться изменить параметр на один запуск или быстро переключаться между готовыми наборами настроек. Для этого в Codex есть два инструмента.
Временное разовое изменение: параметр -c / --config (без редактирования файлов)
Если нужно быстро проверить параметр, переопределите его при запуске в консоли:
# Приоритетный способ — использование выделенного флага (при наличии)
codex --model gpt-5.4
# Общий способ переопределения любых параметров через -c / --config
codex --config model='"gpt-5.4"'
codex -c log_dir=./.codex-logДва важных нюанса из официального руководства:
- Значения передаются в формате TOML, а не JSON. Строковые переменные требуют кавычек (пример:
model='"gpt-5.4"', внешние одинарные кавычки нужны для экранирования в shell, двойные — для TOML). Заключайте параметры в кавычки для исключения ошибок парсинга пробелов. - Вложенные параметры пишутся через точку, например:
codex -c mcp_servers.context7.enabled=false.
Этот способ идеален для разового тестирования параметров без изменения файлов конфигурации.
Использование профилей: параметр --profile
Мы упоминали профили в главе 15. Профиль представляет собой отдельный конфигурационный файл в папке CODEX_HOME с именем вида <имя_профиля>.config.toml:
# ~/.codex/deep-review.config.toml
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
approval_policy = "on-request"Вызов профиля осуществляется через параметр --profile:
codex --profile deep-review
codex exec --profile deep-review "review this change"Логика проста: Codex считывает глобальный ~/.codex/config.toml пользователя, а затем накладывает на него файл профиля ~/.codex/deep-review.config.toml. Соответственно, в файле профиля нужно указывать только измененные ключи, дублировать всю глобальную конфигурацию не требуется.
⚠️ Важное изменение в новых версиях! Официальное примечание:
Начиная с версии Codex 0.134.0, параметр
--profileне считывает секции вида[profiles.имя]внутри общегоconfig.toml, выбор профилей через глобальный ключprofile = "имя"также не поддерживается. Перенесите параметры старых профилей в отдельные файлы~/.codex/[имя].config.toml. Поведение зависит от используемой вами версии, сверяйтесь с официальной документацией.
Я использую два основных профиля: quick (легкая модель + только чтение, для изучения кода) и build (мощная модель + запись в рабочей области, для компиляции и написания кода). Запуск команды codex --profile build сразу переводит систему в нужный режим, избавляя от ручной настройки. Это лучшее лекарство от необходимости ручного ввода.
💡 Резюме одной фразой: временное переопределение ключа выполняется через
-c ключ=значение(строковые значения заключаются в кавычки, вложенные параметры пишутся через точку). Переключение наборов настроек выполняется через--profile [имя]при наличии файла~/.codex/[имя].config.tomlв каталогеCODEX_HOME. Старый формат разделов[profiles.x]не поддерживается начиная с версии 0.134.0.
07 Практика: создание файла настроек, временное переопределение и выбор профиля
Теория без практики быстро забывается. Пройдем полную цепочку: создание конфигурации → временное переопределение → выбор профиля. Мы используем минимальный тестовый пример, не требующий сложной настройки окружения. В качестве модели указан индекс gpt-5.5, замените его на доступную вам модель.
Шаг 1. Проверяем наличие глобального файла пользователя (в терминале)
ls -la ~/.codex/config.tomlОжидаемый результат: вывод информации о файле или сообщение о его отсутствии. При отсутствии файла создадим его на следующем шаге.
Шаг 2. Записываем минимальный файл глобальной конфигурации
Создайте файл ~/.codex/config.toml со следующим содержимым (обратите внимание: глобальные ключи объявлены в начале файла, раздел features — в конце):
# ~/.codex/config.toml
model = "gpt-5.5"
approval_policy = "on-request"
web_search = "cached"
[features]
memories = falseОжидаемый результат: файл успешно сохранен и содержит общие параметры по умолчанию.
Шаг 3. Запускаем сессию и проверяем настройки через /status
codexВнутри сессии введите команду:
/statusОжидаемый результат: в окне статуса выведутся параметры используемой модели и стратегии согласования, совпадающие с прописанными в вашем файле. Конфигурация успешно загружена.
Шаг 4. Временное переопределение ключа без изменения файлов
Выйдите из сессии и запустите Codex с параметром живого интернет-поиска:
codex -c web_search='"live"'Введите команду /status для проверки.
Ожидаемый результат: в текущей сессии режим поиска изменится на live, при этом в файле конфигурации по-прежнему сохраняется значение web_search = "cached". При последующем обычном запуске применится исходное значение кэша. Тестирование приоритета параметров командной строки прошло успешно.
Шаг 5. Создание и проверка работы профилей
Создайте файл профиля ~/.codex/quick.config.toml (укажем только отличающиеся локальные настройки):
# ~/.codex/quick.config.toml
model = "gpt-5.5"
sandbox_mode = "read-only"
approval_policy = "untrusted"Запустите Codex с флагом профиля:
codex --profile quickПроверьте статус через /status.
Ожидаемый результат: песочница перейдет в режим read-only, стратегия согласования изменится на untrusted (более строгий контроль по сравнению с глобальным файлом), так как параметры профиля переопределили глобальные ключи. Тестирование работы профилей прошло успешно. Обычный запуск без флага вернет глобальные параметры.
Мы проверили ключевые сценарии: сохранение глобального файла, контроль загрузки через /status, разовое переопределение параметров через -c и запуск именованных профилей через --profile. Любые настройки Codex выполняются по этой схеме.
💡 Резюме одной фразой: выполните на практике последовательность «глобальный файл настроек → проверка статуса через
/status→ разовое переопределение через-c→ создание и запуск профиля безопасности». Это закрепит понимание логики работы конфигураций.
08 Итоги
В этой статье мы разобрали структуру и логику работы конфигурационного файла config.toml — от областей ответственности файлов до приоритетов наложения, запрещенных ключей проектов и использования профилей.
Повторим ключевые выводы:
| Что нужно знать | Ответ | Главная суть |
|---|---|---|
| Отличие от AGENTS.md | Разные файлы | AGENTS.md задает базу знаний, config.toml — логику работы |
| Где хранить | Два пути | Глобально в ~/.codex/config.toml или локально в .codex/config.toml проекта (требует доверия) |
| Приоритеты наложения | Специфичный переопределяет общий | Консоль > проект > профиль > пользователь > система |
| Ограничения безопасности | Проект имеет урезанные права | Системные ключи (model_provider, notify, otel) игнорируются в файле проекта |
| Частые параметры | 7-8 основных ключей | model, approval_policy, sandbox_mode, web_search (кэш по умолчанию) и раздел [features] |
| Разовые правки / Профили | Параметры -c и --profile | Смена настроек на одну сессию через -c или переключение профиля через --profile |
Теперь вы умеете: кучно управлять параметрами Codex из одного файла, разделять настройки на глобальные и локальные, использовать механизм приоритетов и обходить ограничения безопасности локальных конфигураций. Вы знаете назначение ключевых параметров и флагов экспериментальных возможностей, умеете переопределять ключи через командную строку и переключаться между профилями. Конфигурационный файл избавляет от ручного ввода параметров и автоматизирует настройку среды при старте.
Вся рутина с частым ручным вводом параметров происходила из-за отсутствия правильных настроек в config.toml. Теперь вы сможете сэкономить время: если вам приходится часто настраивать определенный параметр, пропишите его в глобальный или локальный конфигурационный файл.
В следующей статье — 19 · Система памяти (Memories и Chronicle). Вы обратили внимание на отключенный по умолчанию параметр memories в разделе [features]? В следующей главе мы разберем его назначение: как научить Codex запоминать ваши предпочтения и структуру проекта, чтобы он работал как постоянный ассистент, знающий контекст предыдущих сессий. Небольшой вопрос на размышление: в прошлых статьях агент получил возможность «видеть экран», теперь он получит возможность «помнить информацию». Насколько эффективнее станет ассистент, умеющий видеть и запоминавать?