Skip to main content
Codex CLIOpenAIAI automation

Codex CLI 5.6 зламав процеси: що робити

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

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

Я зацікавився цією історією не через галас, а тому що такі збої одразу б'ють по AI-автоматизації, особливо якщо 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-інтеграція на рівні оточення.

Що це змінює для бізнесу та автоматизації

Якщо Codex CLI вбудований у продовий процес, головний висновок простий: не можна прив'язувати критичний потік до автооновлення без піннінгу за версією. Одне оновлення — і команда втрачає години не на розробку, а на розкопки оточення.

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

Я такі вузькі місця регулярно бачу в клієнтських процесах: сам інструмент може бути потужним, але слабка AI-архітектура навколо нього все псує. У Nahornyi AI Lab ми саме розбираємо такі вузли, щоб автоматизація з AI не руйнувалася від одного апдейту. Якщо у вас схожа історія, можна спокійно подивитися ваш workflow і зібрати нормальну схему з резервом, логами й передбачуваним оновленням, а не жити в режимі «вранці все працювало, ввечері ні».

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

Поділитися статтею