Когда Codex работает сам

До сих пор в треке за Codex сидел человек: ставил задачу, одобрял команды, читал дифф. В этом курсе человека в цикле нет. Codex запускается из GitLab CI, по расписанию или из вашего собственного сервиса, а результат забирает программа. Это другой режим работы, и у него свои правила.

Что меняется без человека

В интерактивной сессии страховкой служат одобрения (approvals): агент спрашивает, вы отвечаете. В автоматизации спрашивать некого, поэтому всё решается заранее:

• Права задаются до запуска. Песочница (sandbox) и политика одобрений фиксируются флагами или конфигом. Если что-то не разрешено заранее, оно просто не выполнится.
• Результат читает программа. Нужен стабильный формат: JSON по схеме, поток событий, файл с итоговым сообщением.
• Входные данные чужие. Текст merge request, коммиты, логи и описания задач пишут люди, иногда посторонние. Для агента это потенциальный канал prompt injection.
• Секреты рядом. В CI лежат ключи и токены. Агент работает в том же окружении, и это надо учитывать в архитектуре пайплайна.

Если вы не проходили уроки про песочницу, начните с «Песочницы и одобрений» и «Песочницы всерьёз» — дальше мы на них опираемся.

Карта инструментов

Правило выбора простое: начинайте с самого узкого инструмента. Большинство задач агентства — проверка MR, разбор упавших тестов, сводка изменений — закрываются одним вызовом codex exec в job. SDK нужен, когда Codex становится частью вашей программы. App Server — когда вы строите полноценный клиент с потоком событий и одобрениями.

Чем закончится курс

Вы соберёте рабочий .gitlab-ci.yml с Codex, настроите ревью merge request, сделаете автопочинку упавших тестов с обязательной проверкой человеком и разберётесь, где в такой схеме дыры в безопасности. Факты сверены с документацией Codex на октябрь 2026 года. Флаги меняются от версии к версии, поэтому перед внедрением сверяйтесь с codex exec --help.