Codex застряг між пам’яттю та надмірною обережністю

Що саме ламається в роботі Codex

Тут ідеться не про одну несправність, а одразу про три пов’язані симптоми: вигадані деталі, ігнорування інструкцій і нескінченні запити на підтвердження. Станом на 22 серпня 2026 року головним первинним джерелом є не примітка до релізу, а користувацька гілка зі скаргами на модель, названу GPT-5.6-Sol.

Найпоказовіший епізод стосується pull request. Агент отримав пряму команду створити й злити PR, створив його, але потім окремо попросив дозволу на merge. Після звичайного підтвердження він зажадав ще й суворо сформульованої фрази схвалення.

Це вже не корисна перевірка перед незворотною дією. Це цикл уточнень, у якому інтерфейс безпеки починає сперечатися з чітко висловленим наміром користувача. Для автономного coding agent така втрата ініціативи критична: завдання формально рухається, але агент перекладає кожен значущий крок назад на людину.

У тій самій гілці розробники повідомляють про жорстко закодовані фрагменти логіки, порушення інструкцій і можливе скорочення лімітів. Останнє лишається припущенням користувачів: у вихідних матеріалах немає підтверджених цифр або офіційного опису зміни.

Ще один можливий чинник — локальна пам’ять. Документація Codex про пам’ять описує файлове зберігання у ~/.codex/memories/, зокрема memory_summary.md, MEMORY.md і raw_memories.md. Згодом там можуть накопичуватися підсумки сесій і матеріали, пов’язані зі skills, тому очищення каталогу є розумним діагностичним кроком.

Але це не готове виправлення. Один з учасників уже очищав memories і skills, а також перевіряв чисту конфігурацію, проте проблему не усунув. Отже, джерело може бути вище: у системних інструкціях, політиці підтверджень або поточній поведінці моделі.

Чому надмірна обережність не дорівнює надійності

Головний наслідок простий: автономність зникає саме там, де вона найбільш потрібна. Додаткове підтвердження перед видаленням бази даних може бути виправданим, але повторне погодження вже схваленого merge перетворює захист на гальмо робочого процесу.

Спершу я б розділив два класи збоїв. Очищення пам’яті перевіряє вплив накопиченого контексту; чиста сесія допомагає виключити локальні skills і старі підсумки. Якщо цикл зберігається, проблема ймовірніше полягає у загальній політиці агента, а не в конкретному робочому каталозі.

Дослідження збоїв агентів описують схожі режими як Operational Hallucination і Safety Drift: агент повторює дії, втрачає початкове обмеження або поводиться надто обережно в межах дозволеного завдання. Це не доводить причину конкретних скарг, але добре пояснює форму спостережуваної відмови.

Поки немає офіційного запису про зміну поведінки, говорити про навмисне посилення guardrails зарано. Втім, інженерний сигнал уже тривожний: агент, який боїться завершити дозволену операцію, може бути безпечнішим на папері, але значно менш керованим у реальній розробці.

Раніше ми розглядали збій саморефлексії Claude, за якого prompt injection може перетворити взаємодію з агентом на відмову в обслуговуванні. Це конкретний безпековий відповідник циклів уточнення та жорстко закодованої логіки, розглянутих тут.