Codex не смог сжать контекст: как сохранить сессию и найти границу сбоя

Error running remote compact task означает, что Codex не завершил сжатие истории, необходимое для продолжения длинной сессии. Это не диагноз сети и не доказательство, что закончился лимит аккаунта. За одной оболочкой могут скрываться оборванный stream, тайм-аут, отсутствующий маршрут у provider, несовместимый параметр, переполненный контекст, блокировка содержимого, ошибка разбора ответа или дочерний процесс, который не завершился.

Прежде чем что-либо сбрасывать, сохраните состояние. Скопируйте сообщение целиком, запишите версию и интерфейс Codex, время с часовым поясом, способ входа и последний подтверждённый шаг. Проверьте diff, новые файлы, активные процессы и удалённые задания. Сбой сжатия не отменяет автоматически уже выполненную запись. Повторять внешнее действие можно только после проверки частичного результата.

Не отделяйте префикс от продолжения

Текст после двоеточия указывает, какую границу разумно проверять первой:

• stream disconnected before completion или stream closed before response.completed — поток завершился до финального события. Сохраните те же аккаунт, модель, проект и маршрут, затем один раз возобновите эту же сессию и сравните последнюю видимую операцию.
• request timed out или сообщение о временно высокой нагрузке — один запрос не уложился в ожидание. Подождите короткий интервал и сделайте один повтор; параллельные копии задачи только усложнят картину.
• 404 Not Found — фактический base URL может не иметь compact endpoint. Это особенно важно для пользовательского provider или прокси, у которого обычный /responses работает, а compaction не реализован.
• Unknown parameter, service_tier, неизвестный variant или неожиданный формат — проверяйте договор клиента, модели и provider, а не качество сети. Сохраните полное тело ответа и не меняйте одновременно модель и настройки.
• input exceeds ... context window либо ran out of room — сама история уже не помещается в запрос сжатия или выбран другой контекст модели. Нужна короткая передача состояния в новую сессию, а не бесконечный повтор.
• Request blocked — запрос был отклонён; сведите пример к минимальному содержимому. Многократный повтор одинакового текста не проверяет транспорт.
• timeout waiting for child process to exit — Codex ждёт локальный или удалённый процесс. Ищите watcher, dev server, ожидание stdin, дерево потомков или незакрытый handle.

Если интерфейс показывает только общий префикс, укажите, сработало ли автоматическое сжатие или команда /compact, и сохраните session/request ID. Одного полного события достаточно для полезной диагностики; число безразличных повторов — нет.

Уточните, кто выполняет compaction

В официальном справочнике Compact a response OpenAI описывает публичный POST /responses/compact. Руководство по compaction называет результат непрозрачным состоянием для продолжения: его передают дальше, а не разбирают как стабильный текстовый summary.

Из этого не следует, что все варианты доступа взаимозаменяемы. Вход через ChatGPT использует маршрут клиента Codex; прямой ключ OpenAI API зависит от проекта, модели и публичного endpoint; пользовательский provider/base URL обязан отдельно поддерживать путь, параметры и поток событий. Терминал, приложение, контейнер и Remote SSH могут иметь разные proxy, DNS, сертификаты и переменные окружения. Открывающийся сайт подтверждает только маршрут браузера.

Одна попытка должна отвечать на один вопрос

Текущая официальная документация команд Codex разделяет операции. /status показывает состояние сессии, /compact запускает сжатие текущего чата, codex resume продолжает интерактивную сессию, а codex exec resume — подходящий неинтерактивный запуск. codex doctor собирает диагностический отчёт; /feedback открывает форму обратной связи с возможностью приложить логи.

Практический порядок выглядит так:

1. Зафиксируйте изменения файлов, процессы и операции записи, которые могли уже выполниться.
2. Сохраните полную ошибку, версию, интерфейс, тип авторизации/provider и идентификатор сессии.
3. Для одиночного stream/timeout сбоя один раз возобновите исходную сессию без смены условий.
4. Для стабильного 404, параметра, parser или процесса измените только названную границу.
5. Начните с чтения или легко обратимого действия и лишь затем возвращайте прежнюю нагрузку.

Если resume сразу снова запускает неудачное сжатие, прекратите цикл. Подготовьте небольшой handoff: цель, выполненные шаги, решения, изменённые файлы, проверки, открытый риск и следующее действие. После этого fork или новая сессия сохранят задачу даже при потере лишней части диалога.

Не делайте массовый reset первым экспериментом

Удаление .codex или кэша способно убрать историю, конфигурацию и доказательства вместе с повреждённым объектом. Сначала нужна резервная копия и конкретный признак повреждения. Смена модели одновременно меняет способности, окно контекста и иногда маршрут; успех после неё не устанавливает исходную причину. Увеличение timeout полезно только тогда, когда та же операция стабильно завершается немного позже. Оно не исправляет 404, неверный параметр, блокировку, crash или deadlock.

Если полный ответ содержит HTTP 429, используйте отдельную диагностику лимитов Codex. Когда неизвестно, действительно ли остановилось сжатие, начните с карты тайм-аутов Codex. Если данные указывают на сеть команды, proxy или приоритет конфигурации, переходите к руководству по sandbox и config.toml.

Для повторяемого сбоя подготовьте минимальный отчёт: версия и поверхность Codex, ОС, тип входа, provider/base URL без секретов, полный текст и время, session/request ID, последняя завершённая операция, способ запуска compaction и короткое воспроизведение. Перед отправкой удалите токены, адреса, приватные prompts, код и идентификаторы проекта.

Надёжное восстановление начинается не с вопроса «сколько раз повторить», а с вопроса «какая граница названа в суффиксе». Сначала сохраните работу, затем сделайте следующую попытку источником новых доказательств.