Skip to main content
Codex CLIOpenAIAI automation

Codex CLI 5.6 сломал процессы: что делать

После обновления Codex CLI до 5.6 у части пользователей сломались рабочие сценарии, хотя полной официальной несовместимости OpenAI не подтверждала. Для бизнеса это сигнал: AI automation на CLI-инструментах нельзя держать без запасного контура, ручного контроля обновлений и управления кэш-памятью.

Технический контекст

Я зацепился за эту историю не из-за шума, а потому что такие сбои сразу бьют по AI automation, особенно если Codex CLI у вас сидит в локальных пайплайнах или CI/CD. И вот тут у меня вопрос не к модели, а к обвязке: OpenAI не выпускала явного признания тотальной поломки, но по факту workflows у людей посыпались после 5.6.

Я просмотрел, что подтверждается сообществом. Картина неприятная, но не мистическая: на Linux у части команд GPT-5.6 работает нестабильно или не заводится вовсе, на Windows обновление упирается в права доступа, а интерактивный picker моделей местами не показывает GPT-5.6, хотя запуск через флаг проходит.

То есть проблема выглядит не как «все умерло», а как смесь регрессий по платформам, sandbox-ограничений и старого кэша. Вот почему у одного разработчика все взлетает на macOS, а у другого на Linux тот же сценарий падает без внятного объяснения.

Из практических обходов сейчас вижу три самых полезных. Первый: переустановить CLI вручную, например через npm, если автообновление застряло. Второй: убить app-server и очистить models_cache.json. Третий: не ждать picker, а дергать нужную модель напрямую через -m gpt-5.6-sol.

Еще я бы сразу включал подробные логи и отдельно проверял права на каталоги, особенно если у вас Full Auto режим или организационный аккаунт с нетривиальной авторизацией. Такие штуки часто маскируются под «модель сломалась», хотя реально отвалилась AI integration на уровне окружения.

Что это меняет для бизнеса и автоматизации

Если у вас Codex CLI встроен в продовый процесс, главный вывод простой: нельзя завязывать критичный поток на автообновление без pinning по версии. Одно обновление, и команда теряет часы не на разработку, а на раскопки окружения.

Выигрывают те, у кого есть изоляция версий, fallback-сценарий и отдельная проверка CLI после апдейта. Проигрывают команды, где AI implementation сделана «на доверии», без тестового контура и без наблюдаемости.

Я такие узкие места регулярно вижу в клиентских процессах: сам инструмент может быть сильным, но слабая AI architecture вокруг него все портит. В Nahornyi AI Lab мы как раз разбираем такие узлы, чтобы automation with AI не рушилась от одного апдейта. Если у вас похожая история, можно спокойно посмотреть ваш workflow и собрать нормальную схему с резервом, логами и предсказуемым обновлением, а не жить в режиме «утром все работало, вечером нет».

Мы ранее рассматривали, как Codex 5.2 на Raspberry Pi превращается из многообещающего демо в миф при отсутствии реальной архитектуры. Похожая ситуация с крахом Codex CLI после обновления показывает, что заверения разработчиков не всегда спасают от провала на практике.

Поделиться статьёй