Non-Interactive Mode: codex exec
📚 Навигация по серии: Предыдущая статья 〔27 Автоматизация и CI/CD〕 описала общую картину автоматической работы Codex в CI: какие задачи подходят для автоматизации и как развернуть окружение. В этой статье мы сфокусируемся на ключевой команде:
codex exec— неинтерактивном режиме работы, при котором ИИ получает задачу одной командой, выполняет её в фоновом режиме и завершает работу. В следующей статье 〔29 Интеграция со Slack, Linear и SDK〕 мы разберем интеграцию Codex с мессенджерами и таск-трекерами.
Друзья, сегодня мы обсудим команду, без которой невозможно представить серьезную автоматизацию, — codex exec.
В 08-й статье про интерфейс командной строки (CLI) я кратко упоминал её, сравнивая с доставкой еды: вы делаете заказ (отправляете промпт), кухня готовит блюдо за закрытыми дверями, и курьер приносит его вам (результат выводится в консоль). Вам не нужно присутствовать при готовке. В этой главе мы заглянем на кухню и разберем, как устроен этот процесс изнутри, как форматируются результаты и как встраивать эту команду в конвейеры автоматизации.
Зачем нужна отдельная статья про эту команду? Интерактивный режим (запуск через команду codex с открытием полноэкранного интерфейса) имеет существенное ограничение: он предполагает обязательное присутствие человека перед монитором, который читает диалог, одобряет операции и просматривает diff изменений. Но если вам нужно автоматически анализировать коммиты за день, отправлять патчи при сбоях сборки в CI или парсить логи ошибок — человека за компьютером нет. Интерактивный интерфейс в таких условиях не просто бесполезен, он заблокирует процесс сборки, бесконечно ожидая подтверждения от пользователя. Команда codex exec создана как раз для сценариев работы «без человека».
Освоение codex exec — это важный шаг перехода от простого использования Codex как умного чата к его интеграции в качестве надежного компонента ваших внутренних ИТ-процессов.
Прочитав эту статью, вы получите:
- Понимание ключевых различий между интерактивным и неинтерактивным режимами и список подходящих сценариев для
codex exec - Разбор важнейшего архитектурного решения: вывод служебной информации в поток stderr, а полезной нагрузки — в stdout, что упрощает интеграцию с Unix-пайпами
- Инструкцию по совместному использованию флага
--json(для логирования процессов в формате JSONL) и ключа-o/--output-last-message(для записи итогового сообщения в файл) в задачах CI - Описание работы песочницы: почему по умолчанию в неинтерактивном режиме включен доступ «только чтение» и как безопасно давать права на запись
- Способы передачи данных через стандартный ввод (stdin): сценарии с передачей контекста через пайп и запуск промпта непосредственно из stdin через
codex exec - - Пошаговую инструкцию по созданию и запуску первого циклического скрипта автоматизации на базе
codex exec
⚠️ Описание флагов, команд и поведения систем в этой статье основано на официальной документации. Названия моделей и версии утилит могут меняться, используйте актуальные параметры из вашей локальной среды разработки.
01 Сфера применения: для каких задач создан неинтерактивный режим
Сразу к главному: неинтерактивный режим codex exec разработан для сценариев, в которых отсутствует оператор-человек. Это скрипты автоматизации, задачи по расписанию и конвейеры сборки CI/CD, где некому нажимать кнопки подтверждения операций, а результат работы ИИ должен быть передан следующей программе в цепочке.
В предыдущих статьях мы работали в интерактивном режиме: запускали команду codex, открывали полноэкранное TUI (текстовый интерфейс пользователя), отправляли запросы и подтверждали изменения. Это удобно, пока вы находитесь на месте.
Но для ряда задач такой подход неприменим:
1. Монотонные повторяющиеся задачи. Например: «каждое утро собирать список коммитов за сутки и формировать из них релизные заметки (release notes)». Задача простая, но рутинная. Делать это вручную каждый день через чат неудобно.
2. Запуск в окружениях без графического интерфейса. На серверах сборки CI, удаленных машинах или внутри контейнеров Docker нет возможности запустить TUI.
3. Передача результатов работы ИИ в другие утилиты. Например, если вам нужно сгенерировать Markdown-таблицу на основе логов ошибок и отправить её в комментарии к PR через команду gh pr comment. Для этого вывод Codex должен быть абсолютно чистым, без элементов интерфейса и служебных сообщений.
Аналогия: вендинговый автомат vs обслуживание на кассе. Интерактивный режим похож на заказ у кассира: вы говорите, что нужно, повар готовит, в процессе вас могут спросить «добавить ли сироп», после чего выдают заказ. Команда codex exec — это вендинговый автомат: вы нажимаете кнопку (отправляете команду), механизм выдает товар в лоток (выводит результат в stdout). В процессе нет диалога, ИИ не задает вопросов и выполняет задачу автономно. Это позволяет запускать автоматы круглосуточно, тысячами штук одновременно.
Типичные сценарии использования codex exec:
- «Сборка CI упала, нужно локализовать ошибку и отправить коммит с исправлением» — процесс выполняется полностью автоматически в облачном контейнере.
- «Собрать историю коммитов и сохранить релизные заметки в файл» — рутинная задача, завернутая в простой bash-скрипт.
- «Передать лог ошибки в ИИ для получения рекомендаций по устранению» — запуск одной командой без необходимости копировать текст в чат.
💡 Резюме в одном предложении: Режим
codex execразработан для автономного выполнения задач (по аналогии с вендинговым автоматом): при запуске в скриптах, на серверах без TUI и в сценариях, где результат должен быть передан по цепочке другим программам.
02 Первое знакомство: базовый синтаксис команды
Несмотря на грозные термины вроде «неинтерактивный режим», базовый синтаксис команды предельно прост: вы пишите codex exec, а в кавычках указываете задачу, которую нужно выполнить.
codex exec "Проанализируй структуру репозитория и выдели 5 ключевых особенностей архитектуры"Codex прочитает файлы в текущей папке, составит план действий, выведет отчет в консоль и завершит работу, вернув управление терминалу. Он не открывает TUI и не ждет ввода от пользователя. Это и есть неинтерактивный режим: задача выполнена — утилита завершила работу.
Аналогия: отправка технического задания по электронной почте. Интерактивный режим — это телефонный звонок, где вы обсуждаете детали в реальном времени. Команда codex exec — это отправка письма с ТЗ. Вы должны сразу четко описать задачу и требования к результату, так как в процессе выполнения ИИ не сможет задать вам уточняющие вопросы.
Несколько примеров полезных флагов:
# Короткий псевдоним codex e эквивалентен полной команде codex exec
codex e "Объясни назначение этого проекта"# Использование другой модели для конкретного запуска (имя модели приведено для примера)
codex exec -m gpt-5.5 "Проверь изменения на наличие потенциальных багов"# Запуск без сохранения истории этой сессии на диске (флаг --ephemeral)
codex exec --ephemeral "Сделай быстрый обзор кода и предложи улучшения"Важное отличие безопасности: в интерактивном режиме перед выполнением опасных действий (например, изменением файлов) утилита спрашивает вашего согласия. В режиме codex exec подтверждения не запрашиваются. То, насколько глубокие изменения ИИ может внести в систему, определяется только флагом песочницы при запуске (подробнее в разделе 04).
⚠️ Важное требование: наличие Git-репозитория. По умолчанию Codex требует, чтобы запуск происходил внутри репозитория Git (для защиты от случайного изменения неверсионированных файлов). Это ограничение можно обойти с помощью флага
--skip-git-repo-check, но делайте это только в том случае, если полностью уверены в безопасности окружения.
💡 Резюме в одном предложении: Запуск
codex exec "инструкция"(короткая формаcodex e) выполняет задачу в фоновом режиме и завершает работу без вывода TUI и запросов на подтверждение. Команда по умолчанию должна запускаться в Git-репозитории, для обхода используйте--skip-git-repo-check.
03 Важнейшая особенность: разделение потоков stdout и stderr
Этот раздел описывает ключевое архитектурное решение, благодаря которому codex exec легко интегрируется с Unix-пайпами.
В процессе работы Codex выводит много информации: свои размышления, список запускаемых команд, статус чтения файлов. Но для работы скрипта обычно требуется только финальный результат (например, сгенерированный текст отчета). Если бы служебные сообщения и полезная нагрузка выводились в один поток, вам пришлось бы писать сложные регулярные выражения для очистки текста.
Разработчики Codex решили эту проблему разделением потоков:
Вся служебная информация направляется в поток stderr (стандартный поток ошибок), а финальный ответ ИИ — в поток stdout (стандартный вывод). Эти потоки независимы. Пайпы | и перенаправления > в Linux по умолчанию перехватывают только данные из stdout. Это позволяет легко отсекать служебный шум.
Аналогия: строительная площадка с отдельным входом для материалов и выходом для готовой продукции. На стройке шумно: работают краны, шумит бетономешалка, рабочие обсуждают чертежи (это поток stderr, служебный шум процесса). Готовое здание сдается через парадные ворота (это stdout, полезный результат). Прохожие видят шум стройки, но при приемке объекта покупатель получает только чистые ключи от квартиры, без строительного мусора.
Пример перенаправления чистого результата в файл:
codex exec "Составь список изменений на основе коммитов за неделю" | tee release-notes.mdОжидаемый результат: В консоли вы увидите лог выполнения задачи (служебный поток stderr), а по завершении — итоговый отчет. При этом в созданный файл release-notes.md запишется только чистый текст отчета, без логов работы ИИ.
Варианты перенаправления потоков:
| Задача | Команда | Описание |
|---|---|---|
| Записать только результат в файл | codex exec "..." > out.md | stderr выводится в консоль, чистый stdout записывается в файл |
| Записать результат и вывести в консоль | codex exec "..." | tee out.md | Утилита tee дублирует чистый stdout в файл и на экран |
| Передать результат следующей программе | codex exec "..." | pbcopy | В буфер обмена попадет только чистый финальный ответ ИИ |
| Сохранить логи работы и отчет отдельно | codex exec "..." > out.md 2> log.txt | stdout записывается в out.md, служебный stderr — в log.txt |
Типичная ошибка новичков — использование конструкции 2>&1 (объединение потоков) при попытке сохранить результат. В этом случае в файл попадет вся служебная информация, что затруднит его автоматический разбор.
💡 Резюме в одном предложении: Команда
codex execвыводит логи работы в stderr, а итоговый ответ — в stdout, благодаря чему перенаправления>и пайпы|по умолчанию получают очищенный от служебного шума результат работы ИИ.
04 Безопасность и песочница: режим «только чтение» по умолчанию
Поскольку в неинтерактивном режиме подтверждения операций не запрашиваются, безопасность работы контролируется настройками песочницы.
По умолчанию codex exec запускается в режиме изоляции read-only (только чтение). ИИ может анализировать файлы и структуру каталогов, но не имеет права изменять их или выполнять команды, влияющие на систему. Для записи изменений требуется явное переключение режима.
Аналогия: вызов мастера для диагностики. Если вы вызываете мастера только для оценки стоимости ремонта (режим read-only), он может осмотреть трубы, но не имеет права ничего менять без вашего присутствия. Если же вы хотите, чтобы он устранил течь, вы должны выдать ему инструменты и явно разрешить проведение работ (режим workspace-write).
Режим песочницы настраивается флагом --sandbox (короткая форма -s):
| Уровень изоляции | Разрешенные операции | Сфера применения |
|---|---|---|
read-only (по умолчанию) | Чтение файлов, анализ кода. Запись на диск запрещена. | Аудит безопасности, ревью кода, составление отчетов. |
workspace-write | Чтение и запись файлов в пределах рабочей папки проекта. | Автоматическое исправление багов, рефакторинг, создание файлов. |
danger-full-access | Полный доступ к операционной системе раннера. | Запуск в изолированных контейнерах или одноразовых CI-машинах. |
Примеры команд:
# Безопасный запуск: аудит кода без риска изменения файлов
codex exec "Проверь изменения на соответствие стандартам"# Запуск с разрешением на редактирование файлов в папке проекта
codex exec --sandbox workspace-write "Исправить форматирование кода в проекте"# Запуск в изолированном облачном контейнере без ограничений
codex exec --sandbox danger-full-access "Собрать проект и запустить тесты"Важные замечания по безопасности:
1. Флаг --full-auto устарел. В старых скриптах вы могли встретить опцию codex exec --full-auto. Сейчас она признана устаревшей (deprecated) и выводит предупреждение. Вместо неё используйте параметр --sandbox workspace-write.
2. Не используйте danger-full-access на рабочих машинах. Этот режим отключает все ограничения безопасности. Используйте его только внутри одноразовых контейнеров на серверах сборки CI/CD.
3. Изоляция конфигураций. Флаги --ignore-user-config (игнорировать локальные файлы конфигурации) и --ignore-rules (игнорировать локальные правила выполнения) позволяют гарантировать идентичность поведения ИИ на разных машинах разработчиков в команде.
Если вы забудете указать --sandbox workspace-write при запуске сценария исправления ошибок, Codex отработает, но не сможет сохранить изменения на диске.
💡 Резюме в одном предложении: Неинтерактивный режим по умолчанию запускается в безопасном режиме
read-only. Для записи изменений в файлы проекта необходимо явно передать параметр--sandbox workspace-write.
05 Структурированный вывод: использование флага --json и ключа -o
Для автоматической обработки результатов работы ИИ в скриптах обычный текст подходит плохо. Codex предлагает два инструмента для структурирования вывода.
Инструмент 1: Флаг --json (вывод событий в JSON-формате). При добавлении флага --json (или --experimental-json) поток stdout переключается в формат JSON Lines (JSONL). Каждое событие в процессе выполнения (запуск шага, чтение файла, ошибка) выводится в виде отдельной строки JSON.
Аналогия: получение подробного лога с датчиков вместо общего описания. Вместо рассказа «самолет летит нормально» вы получаете ежесекундный поток данных: высота, скорость, крен. Это позволяет программе-обработчику точно отслеживать прогресс выполнения задачи.
Пример команды с обработчиком JSON:
codex exec --json "Составь отчет по структуре проекта" | jqФормат выводимых событий (каждая строка — валидный JSON-объект):
{"type":"thread.started","thread_id":"0199a213-81c0-7800-8aa1-bbab2a035a53"}
{"type":"turn.started"}
{"type":"item.completed","item":{"id":"item_3","type":"agent_message","text":"Проект содержит папки docs и src."}}
{"type":"turn.completed","usage":{"input_tokens":24763,"output_tokens":122}}Это позволяет легко парсить статусы выполнения, перехватывать ошибки и вести учет потраченных токенов.
Инструмент 2: Ключ -o / --output-last-message (запись финального ответа в файл). Если вам не нужны логи процессов, а нужен только итоговый текстовый ответ ИИ, сохраненный в файл, укажите ключ -o <путь к файлу>:
codex exec "Собери метаданные проекта" -o ./summary.mdПри этом финальный ответ запишется в указанный файл, но также продублируется в поток stdout, что позволяет использовать его в пайпах далее.
Сравнение инструментов вывода:
| Задача | Инструмент | Формат результата |
|---|---|---|
| Построчный анализ шагов выполнения, учет токенов | --json | JSONL-поток в stdout |
| Сохранение финального текста ответа в файл | -o <путь> | Текстовый файл на диске + дублирование в stdout |
| Полный контроль выполнения в CI | --json + -o одновременно | Логи событий парсятся из stdout, чистый отчет пишется в файл |
Совместное использование --json и -o рекомендуется для интеграции в CI/CD: вы контролируете ход выполнения по логам событий, а готовый артефакт сохраняете на диск.
Для сложных сценариев можно передать JSON Schema через параметр --output-schema, чтобы обязать Codex вернуть ответ строго в соответствии с заданной структурой полей.
💡 Резюме в одном предложении: Флаг
--jsonпреобразует вывод в построчный поток JSON-событий для разбора скриптами, а ключ-oпозволяет сохранить итоговый текст ответа в файл, не блокируя вывод в stdout.
06 Передача данных через стандартный ввод (stdin)
Одной из самых удобных функций codex exec в консоли является возможность передачи данных на вход ИИ через стандартный ввод (stdin).
Это необходимо, когда у вас уже есть результат работы другой программы (например, логи ошибок или вывод команды curl), и вы хотите передать их на анализ Codex.
Различают два способа передачи данных через stdin:
Сценарий 1: Инструкция в параметрах, данные в stdin
Используется, когда вы пишите команду ИИ текстом, а в качестве контекста (данных для анализа) передаете вывод предыдущей команды.
При наличии данных в stdin и текстовой инструкции в параметрах, Codex воспримет текст параметров как команду, а данные stdin — как контекст для её выполнения.
Пример передачи логов тестов для поиска причин падения сборки:
npm test 2>&1 \
| codex exec "Проанализируй ошибки тестов и предложи исправление" \
| tee test-summary.mdОжидаемый результат: Логи тестов (включая ошибки из stderr благодаря 2>&1) передаются на вход Codex. ИИ анализирует их, выводит рекомендации на экран и записывает их в файл test-summary.md.
Пример анализа логов веб-сервера:
tail -n 200 access.log \
| codex exec "Найди подозрительные запросы в логе и сгруппируй их по IP" \
> security-report.mdСценарий 2: Передача всей инструкции через stdin (символ -)
Используется, когда и инструкция, и данные формируются динамически предыдущим скриптом. Для этого в качестве параметра передается символ -:
# Передача содержимого текстового файла в качестве промпта
cat prompt_template.txt | codex exec -# Формирование сложного запроса через скрипт
printf "Составь отчет по логам:\n\n%s\n" "$(tail -n 50 error.log)" \
| codex exec -Этот метод полезен при использовании заранее подготовленных шаблонов промптов. Вы можете хранить шаблоны в файлах репозитория, наполнять их данными и передавать на выполнение в Codex.
💡 Резюме в одном предложении: При передаче данных через stdin: текстовый параметр команды задает инструкцию, а stdin передает контекст. Если передать символ
-, то все содержимое stdin будет воспринято как единая инструкция ИИ.
07 Продолжение сессии: команда codex exec resume
Неинтерактивный режим поддерживает работу с контекстом предыдущих запусков. Если вам нужно выполнить задачу в несколько этапов, используйте команду resume.
Аналогия: передача эстафетной палочки. Первый бегун (первый запуск codex exec) завершает свой этап и передает палочку. Второй бегун (команда resume) продолжает движение с этой же точки, владея всей информацией о пройденном пути. Это экономит токены и сохраняет детали контекста.
Пример двухэтапного сценария:
# Шаг 1: Поиск уязвимостей в коде
codex exec "Проверь этот файл на наличие SQL-инъекций"
# Шаг 2: Исправление найденных ошибок в контексте предыдущей сессии
codex exec resume --last "Исправь найденные уязвимости"Параметр --last указывает, что нужно продолжить последнюю сессию в текущем каталоге. Для обращения к конкретной исторической сессии используйте её идентификатор (ID):
codex exec resume <SESSION_ID> "Продолжи выполнение задачи"Флаг --all позволяет искать сессии во всех каталогах системы. Обратите внимание, что сессии, запущенные с флагом --ephemeral (без сохранения логов на диске), продолжить с помощью resume невозможно.
💡 Резюме в одном предложении: Команда
codex exec resume --lastпозволяет продолжить выполнение задачи в контексте предыдущего запуска, используя историю сессии на диске.
08 Практика: пишем скрипт пакетной обработки файлов
Напишем простой bash-скрипт, который использует codex exec для циклической обработки файлов в репозитории.
Для выполнения примера требуется установленный Codex CLI и инициализированный Git-репозиторий с несколькими текстовыми файлами.
Шаг 1: Запуск тестовой команды в консоли
codex exec "Напиши краткое описание проекта на одну строку"Ожидаемый результат: Утилита выведет краткое описание и завершит работу. Мы убедились в работоспособности CLI.
Шаг 2: Проверка перенаправления потоков
codex exec "Напиши краткое описание проекта" > description.txtОжидаемый результат: Логи работы отобразятся в консоли, а итоговый ответ запишется в файл description.txt. Убедитесь, что в файле нет служебных логов.
Шаг 3: Проверка JSON-вывода
codex exec --json "Покажи список файлов в репозитории"Ожидаемый результат: Вывод в консоли переключится в формат построчного JSON.
Шаг 4: Запись финального ответа в файл
codex exec "Напиши краткое описание проекта" -o summary.txtОжидаемый результат: Текст описания появится на экране и одновременно запишется в файл summary.txt.
Шаг 5: Написание скрипта пакетной обработки
Создайте bash-скрипт, который обходит все файлы .md в папке и генерирует для каждого краткую аннотацию:
for file in *.md; do
echo "=== Обработка файла: $file ==="
codex exec --ignore-user-config "Напиши краткое описание содержания файла $file на русском языке"
doneОжидаемый результат: Скрипт поочередно обработает каждый Markdown-файл, выводя его имя и сгенерированную аннотацию. Мы получили рабочий пример автономного пакетного обработчика без участия пользователя.
💡 Резюме в одном предложении: Практический тест подтверждает ключевые сценарии: простой запуск → перенаправление stdout → вывод JSONL → запись в файл через
-o→ пакетная обработка файлов в цикле.
09 Итоги
В этой главе мы разобрали неинтерактивный режим работы Codex, предназначенный для автоматизации процессов.
Основные параметры сведены в таблицу:
| Задача | Решение | Ключевой нюанс |
|---|---|---|
| Фоновый запуск задачи | codex exec "инструкция" | Выполняет задачу и завершает работу без вывода TUI |
| Фильтрация логов работы | Перенаправление stdout (>) | Логи пишутся в stderr, полезный ответ — в stdout |
| Редактирование файлов | --sandbox workspace-write | По умолчанию включен безопасный режим read-only |
| Логирование для скриптов | Флаг --json | Выводит события выполнения в формате JSONL |
| Сохранение отчета на диск | Флаг -o <путь> | Записывает ответ в файл, дублируя его в stdout |
| Передача контекста | Пайп stdin | Наполняет контекст ИИ данными из консоли |
| Связывание шагов | codex exec resume --last | Позволяет продолжать сессии для экономии токенов |
Теперь вы умеете:
- Использовать команду
codex execдля запуска Codex в скриптах и задачах автоматизации. - Работать с потоками вывода, отсекая служебные логи от полезной нагрузки с помощью перенаправлений.
- Настраивать права доступа песочницы для неинтерактивного режима.
- Парсить события выполнения в формате JSONL и сохранять результаты в файлы с помощью флага
-o. - Передавать данные на анализ через stdin и связывать несколько запусков в единую сессию через
resume.
Неинтерактивный режим превращает Codex из интерактивного чат-бота в системный инструмент, готовый к интеграции в любые скрипты разработки.
В следующей статье 29 · Интеграция со Slack, Linear и SDK мы разберем интеграцию Codex с внешними сервисами. Мы узнаем, как настроить отправку задач из Slack, как связать Codex с карточками задач в таск-трекере Linear и как использовать SDK для интеграции возможностей Codex в собственные приложения.