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 может превратить взаимодействие с агентом в отказ в обслуживании. Это наглядный пример угрозы безопасности, дополняющий рассмотренные здесь циклы уточнений и хардкод логики.