Codex: «Error submitting message» — причина во второй строке

«Ошибка при отправке сообщения» (в английском интерфейсе — Error submitting message) — не код ошибки сервера. Это общий заголовок уведомления, которое Codex показывает, когда сообщение не удалось отправить: в приложении ChatGPT для компьютера (Codex теперь работает внутри него, раньше было отдельное приложение Codex), в расширении для VS Code и Cursor и в Codex Web. Под заголовком приложение подставляет вторую строку — исходный текст ошибки. Решение зависит именно от неё. Если второй строки нет, клиент вообще не получил текста ошибки, и чаще всего это значит, что запрос не дождался ответа.

На чём основан разбор (по состоянию на 16 октября 2026 года):

• Проверено: строки интерфейса и обработка этой ошибки в установленном приложении ChatGPT 26.1013.31256 для macOS; открытый исходный код app-server в репозитории openai/codex; собственные журналы приложения ChatGPT на одном Mac за 2–16 октября; 34 обсуждения в GitHub openai/codex и ветки форума OpenAI Developer Community.
• Не проверялось: ни одна из ошибок специально не воспроизводилась. Решения ниже взяты из отчётов пользователей. Когда ниже написано «помогло» или «подтвердили авторы отчётов», это значит, что способ сработал у тех, кто об этом написал. Это не рекомендация OpenAI и не гарантия, что он сработает у вас.

С чего начать, пока сообщение не пропало:

1. Скопируйте текст неотправленного сообщения в любое другое место.
2. Прочитайте вторую строку уведомления (или текст ошибки в самом чате) и найдите её в таблице ниже.
3. Прежде чем нажимать «Повторить», убедитесь, что сообщение не дошло. В части отчётов «неудачная» отправка на самом деле запустила работу агента, и повтор запускал ту же задачу второй раз.

«Ошибка при отправке сообщения» в Codex: что значит вторая строка

В коде приложения ChatGPT 26.1013.31256 уведомление собрано из двух частей: заголовка «Ошибка при отправке сообщения» и переменной с текстом исходной ошибки, которая выводится с новой строки. Заголовок одинаковый для любого сбоя, поэтому сам по себе ни о чём не говорит. С той же второй строкой встречаются и заголовки Error creating task и Error creating chat: это та же ошибка, только при создании задачи или чата.

В самом чате на месте неудачного хода (turn — одна пара «запрос — ответ агента») показывается текст исходной ошибки. Если текста нет, остаётся просто Error submitting message — эта запасная строка задана в коде по-английски. Голый заголовок без пояснения обычно означает тайм-аут или оборванное соединение: клиент не дождался ответа и не узнал, что произошло.

Что происходит при отправке. Приложение передаёт сообщение запросом turn/start локальному серверу Codex (app-server), который приложение само запускает на вашем компьютере. В расширении для IDE (сборка 26.513) этот запрос ждёт ответа 30 000 мс. В журналах из отчётов о десктопной версии видна та же граница: mcp_request_timeout method=turn/start … timeoutMs=30000, затем [Composer] submit failed errorMessage=Timeout. Если за 30 секунд ответа нет или сервер вернул ошибку, ход помечается как неудачный.

Сервер может отказать и сам — тогда во второй строке будет его текст. В открытом коде app-server (openai/codex на 16 октября 2026 года) есть, например, такие отказы:

• thread not found: … и invalid thread id — чат с таким идентификатором не загружен или не существует;
• Input exceeds the maximum length of 1048576 characters. — текст длиннее 1 048 576 символов;
• remote image URLs are not supported; use an inline data URL instead — картинка передана ссылкой, а не встроенными данными;
• direct app-server input is not allowed for multi-agent v2 sub-agents — попытка написать напрямую в чат субагента;
• failed to submit turn input: … — сервер не смог принять ввод;
• Server is draining; retry after reconnecting — сервер завершает работу, нужно переподключиться;
• invalid thread settings override: … и ошибки загрузки конфигурации.

Не все эти тексты встречались в отчётах пользователей, а приложение может поставляться с более старой версией app-server, чем в репозитории.

Вторая строка ошибки Codex → причина → что помогло

Сводка по отчётам на GitHub и форуме OpenAI. Подробности, условия и оговорки — в разделах ниже.

Если вашей строки нет в таблице, сверьте её с отказами сервера из предыдущего раздела и поищите точный текст в списке проблем репозитория openai/codex на GitHub.

Перед «Повторить»: дошло ли сообщение на самом деле

«Неудачная» отправка иногда всё-таки доходит до агента. В обсуждении #44781 один из пользователей описал ошибку, которая появилась уже после того, как сообщение было сохранено и ход начался. В #52012 (Windows, ошибка EPERM) часть сообщений дошла до агента, хотя интерфейс показывал сбой, и «Повторить» продублировало и сообщения, и ответы агента.

Механизм виден и в журналах приложения ChatGPT на одном Mac за 2–16 октября 2026 года. Там 156 запросов turn/start с медианой 63 мс, 95-й процентиль — 1 184 мс, максимум — 9 042 мс. Тайм-аутов Timed out waiting for MCP response to turn/start два. В одном из них, 3 октября в запланированной автоматизации, ответ сервера пришёл уже после того, как клиент перестал ждать (response_orphaned). То есть запрос мог выполниться, хотя клиент считал его неудачным. Это одна машина и одна нагрузка, общей частоты эти цифры не показывают.

Само приложение это учитывает. В ChatGPT 26.1013.31256 у сообщения из очереди, доставка которого прервалась, есть своя подсказка: «Не удалось подтвердить доставку. Просмотрите разговор, прежде чем удалить это сохранённое сообщение». По описанию в коде, такое сообщение нельзя безопасно отправить повторно автоматически, поэтому приложение и оставляет проверку вам.

Бывает и наоборот: в отчётах о тайм-аутах и об ошибке agent loop died сообщение вообще не дошло до сервера и не записалось в историю чата. Тогда повторная отправка безопасна. Поэтому проверка нужна в любом случае:

1. Посмотрите, есть ли ваше сообщение в чате и не начал ли агент отвечать или выполнять команды.
2. Если агент работает с файлами проекта, выполните git status в папке проекта: появились ли новые изменения.
3. Некоторые авторы отчётов дополнительно ищут текст сообщения в файлах сессий в ~/.codex/sessions. Эти файлы можно только читать: не редактируйте и не удаляйте их (почему — в разделе про rollout path).
4. Сообщения нет и агент ничего не делает — отправьте его один раз. Сообщение есть — не повторяйте, дождитесь ответа.

Не нажимайте «Повторить» много раз подряд. В обсуждении #50428 после 27 отклонённых повторов для одного чата сервер закрыл соединение, и дальше каждое переподключение получало ответ 403.

Завис один чат или не работает весь Codex

Начните новый чат с короткой задачей в том же проекте.

• Новый чат работает — проблема в конкретном чате. В отчётах о тайм-аутах старый тяжёлый чат отвечал медленно, а новый в том же проекте — быстро; при ошибке agent loop died другие чаты продолжали работать. Дальше ищите решение по второй строке.
• Новый чат тоже не отправляется, а список чатов или моделей не загружается — скорее всего, завис сам локальный сервер Codex. В тех же журналах с Mac тайм-ауты шли пачками сразу по нескольким методам: thread/start и thread/list по 8 раз, thread/resume — 6, model/list и config/read — по 4. Здесь помогает полный выход из приложения (через меню или Cmd+Q, а не закрытие окна) и повторный запуск.

В руководстве OpenAI по устранению неполадок Codex именно эта ошибка не упоминается. Для зависшего чата там советуют проверить, не ждёт ли Codex вашего разрешения на команду, выполнить в терминале простую команду вроде git status и начать новый чат с более коротким и конкретным запросом.

Другие ошибки, похожие на эту, разобраны отдельно. Ответы 429 и 401, обрыв потока — в статье «Ошибка Codex exceeded retry limit 429, 401 и Stream Disconnected». Если расширение не открывается вовсе — Codex could not start в VS Code: причины для WSL, SSH и прокси. Если десктопное приложение в Windows работает просто медленно — как сравнить Codex CLI и Desktop.

«App-server queued follow-up no longer exists» после правки очереди

Эта вторая строка — самая массовая в сентябре: семь обсуждений на GitHub с 11 сентября по 1 октября 2026 года, плюс ветка форума OpenAI об ошибке при редактировании сообщения в очереди. Встречалась в ChatGPT для Windows, macOS и Linux и в расширении VS Code 26.908.40401.

Типичный сценарий: агент ещё отвечает, вы ставите следующее сообщение в очередь, нажимаете «Редактировать» (или отзываете его) и отправляете снова. Реже ошибка появлялась на обычном сообщении в очереди без правки и после автоматического сжатия контекста. Если она возникла, дальше в этом чате не отправляется ничего — ни в режиме очереди, ни при корректировке ответа на ходу (Steer).

Что помогло, по словам авторов отчётов:

• Перейти в любой другой чат и вернуться. Так написали около восьми человек. Один предупредил, что при этом пропали остальные сообщения в очереди, поэтому сначала скопируйте их.
• Дождаться, пока ход закончится, или остановить его, а потом отправить текст как новое сообщение. Один из авторов пишет, что это срабатывает «иногда».

Не помогло: удалить сообщение, многократно перезапускать и обновлять приложение.

13 сентября 2026 года сотрудник OpenAI (etraut-openai) написал в #44781: «Проблема понятна. Исправление готово и войдёт в следующий релиз». Версию он не назвал, и сообщения об ошибке продолжались примерно до 21 сентября на сборках 26.908. В приложении ChatGPT 26.1013.31256 этого текста ошибки уже нет. Вместо него в той же части кода стоит Queued follow-up changed before dispatch. Отсюда вывод, который OpenAI не подтверждала: на текущих сборках старая строка появляться не должна, а сбой с очередью выглядит уже как новая ошибка.

«Queued follow-up changed before dispatch» в VS Code

С 4 по 14 октября 2026 года об этой строке сообщали из расширения для VS Code (сборки 26.930–26.1007, Windows и Linux) в обсуждении #50914. Она появлялась, когда за короткое время отправляли пять–семь сообщений подряд при настройке chatgpt.followUpQueueMode со значением queue.

• Автор отчёта пишет, что повторная отправка в итоге проходила. Перед повтором всё равно проверьте, не дошло ли сообщение.
• Режим Interrupt ошибки не вызывает, но прерывает текущий ответ агента.
• Не помогли перезапуск, повторный вход, очистка кэша и переход в режим Steer.

В обсуждении выложены самодельные правки установленного расширения. Это не решение OpenAI, после обновления они пропадут, а их автор сам показал на симуляции, что в одном из сценариев сообщение может уйти повторно. Ставить их не стоит.

«AbsolutePathBuf deserialized without a base path»: задачи dot в Windows

Полный текст: invalid turn/start params: AbsolutePathBuf deserialized without a base path (код -32602). С конца сентября это самая активная ветка: обсуждения #49477, #50428 и #51593, последние сообщения — 15 октября 2026 года.

Когда возникает: dot создал задачу на подключённом компьютере с Windows (в интерфейсе — «Cloud / Runs on your computer when available»), а вы отвечаете в эту задачу прямо из поля ввода приложения. История задачи при этом читается, а сообщения от самого dot проходят. Сборки — от 26.909 до 26.1007, также ChatGPT в браузере на Windows.

Что помогло авторам отчётов (каждый раз для конкретной задачи):

• Сменить разрешения в поле ввода с «Пользовательский» (Custom) на «Подтверждать за меня» (Approve for me). Подтвердили четыре-пять человек. У одного через некоторое время запросы снова пошли со старыми разрешениями, и ошибка вернулась. «Подтверждать за меня» — режим, в котором запросы агента на разрешения проверяет сам ChatGPT. Это другая политика разрешений, а не та же самая, так что решайте, подходит ли она этому проекту.
• Переключиться на «Полный доступ» (Full Access). Помогло двоим, но они сами подчёркивают, что это расширяет права агента и советом это не считают.
• Продолжить работу в новой локальной задаче (или в Codex CLI внутри WSL) через передачу контекста. Один из авторов перед переходом проверил, что все файлы в рабочем дереве на месте.

Не помогли: перезапуск, перезагрузка, обновление, переустановка, архивирование, «Повторить», новая задача с явно указанной папкой Windows. Ответа сотрудников OpenAI на GitHub и в X по состоянию на 16 октября 2026 года нет.

«Timeout» или ошибка без второй строки

Сюда относятся Timeout / timeout, голый заголовок без пояснения и App server request expired while queued. Отчёты — #23644, #27395, #53353 — идут с мая по октябрь 2026 года, последняя сборка для macOS в них — 26.924.

В этих отчётах ошибка совпадала с такими условиями:

• приложение работало без перезапуска несколько дней (в одном случае около 3,5 дня);
• очень большой чат: файл истории одного из них весил 154 МБ;
• файл ~/.codex/logs_2.sqlite разрастался до 1,4–2,2 ГБ, и к нему обращались несколько процессов Codex сразу;
• от предыдущего запуска остался процесс codex_chronicle;
• процессор был занят другими программами.

Что помогло, по словам авторов:

1. Подождать 1–5 минут и отправить снова (после проверки, что сообщение не дошло).
2. Полностью выйти из приложения и запустить его снова. Помогает, но временно.
3. Начать новый чат. Один из авторов замерил: в старом чате отправка тормозила, в новом в том же проекте — нет.
4. Найти и завершить оставшийся codex_chronicle (проверено на macOS). Найти его можно командой ps -axo pid,lstart,etime,command | grep codex_chronicle: если время запуска старше текущего сеанса приложения, это хвост прошлого запуска. После его завершения у автора отчёта неудачных отправок стало ноль вместо четырёх. В Windows сначала разберитесь, какие фоновые процессы Codex можно завершать.
5. Завершить посторонние программы, сильно загружающие процессор.

Сжатие контекста не помогло. Удалять logs_2.sqlite никто из авторов не советовал и сам этого не делал — последствия неизвестны.

«Cannot steer conversation … without an active turn id» в VS Code

В ветке форума OpenAI «Why did the message fail to submit?» (12–13 октября 2026 года, расширение 26.1007.21434 в Ubuntu) пользователь подробно описал последовательность. Сервер уже записал ход как завершённый, а расширение продолжало вести себя так, будто агент ещё работает. Следующее сообщение отклонялось с Cannot steer conversation … without an active turn id, все последующие — по тайм-ауту. Восстановить работу удавалось только командой Developer: Restart Extension Host из палитры команд VS Code. Учтите, что она перезапускает все расширения и прерывает текущие сессии Codex в этом окне. В той же ветке есть непроверенная идея: открыть новую панель агента Codex и уже из её истории открыть этот же чат.

«agent loop died unexpectedly»: чат перестал принимать сообщения

Полный текст — failed to start turn: internal error; agent loop died unexpectedly или failed to submit turn input: internal error; agent loop died unexpectedly. Отчёты идут с мая по 10 октября 2026 года, ChatGPT для macOS и Windows. Часто сначала появляется Error creating task или Error creating chat, а затем каждое следующее сообщение падает с «Ошибкой при отправке сообщения».

В отчётах ошибке предшествовало одно из следующего:

• агент задал вопрос, а ответа долго не было;
• во время запроса на разрешение закончился лимит (в одном случае пятичасовой лимит Plus, и чат остался мёртвым и после сброса — о сроках сброса см. недельный лимит Codex: когда он сбросится);
• агента попросили закрыть субагентов;
• в долгоживущем чате было много сжатий контекста.

Около шести авторов отчётов вернули чат полным выходом из приложения и повторным запуском, но временно. Один пишет, что помогло обновление приложения, и «мёртвый» чат при этом сохранился. Другие чаты продолжали работать. В одном из отчётов неудачные сообщения не записались в историю чата, то есть новый ход не начался, но перед повторной отправкой всё равно загляните в чат.

«thread not found» и «no client found»

thread not found: … возникала, если отправить сообщение сразу после открытия старого, ещё не загруженного чата, или если окно приложения держало устаревшее состояние чата. Помогли перезапуск приложения или новое окно. Форк чата и повторное чтение его истории не помогли. Последний отчёт — 15 октября 2026 года, ChatGPT для Windows (#54361, только скриншот).

no client found (в X — также no-client-found) встречалась при работе с удалённым хостом по SSH и в нескольких окнах сразу, когда чат «переезжал» к другому окну или клиенту (#49892, сборки ChatGPT 26.928–26.1007). Повторное открытие чата не помогало. Предлагали закрыть второе окно, но никто не подтвердил, что это работает.

Ошибки Windows: EPERM, ENOENT и папка для чата без проекта

EPERM: operation not permitted, rename '…\.codex-global-state.json.tmp-…' -> '…\.codex-global-state.json'. Рядом в журнале — Failed to persist queued submission outcome. Windows 10 и 11, сборки 26.1002–26.1007 (#52012). Опасна тем, что часть сообщений на самом деле доходит до агента, а «Повторить» дублирует и сообщения, и ответы агента. Пересоздание файлов состояния, полный перезапуск и остановка Windows Search не помогли. Пока проверяйте каждое сообщение в чате, прежде чем отправлять его снова.

ENOENT: no such file or directory, mkdir '\\?' в чате без проекта. Причина, найденная автором отчёта: параметр projectlessWorkspaceRoot в разделе [desktop] файла ~/.codex/config.toml указывает на папку, которой больше нет. Он исправил путь на существующую папку и перезапустил приложение. Этот параметр есть в ChatGPT 26.1013.31256.

Unable to resolve projectless chat folder при удалённом управлении компьютером с Windows. Автор отчёта из работающего чата на самом компьютере-хосте создал новый чат в существующем проекте; другой пользователь создал чат без проекта с телефона.

«failed to resolve rollout path»: не удаляйте файлы сессий вручную

failed to resolve rollout path … file does not exist (часто вместе с Codex app-server is not available) в Windows появлялась после того, как файлы сессий в ~/.codex/sessions удалили вручную. Ни один новый чат после этого не создавался (#30924). Один из авторов восстановил недостающий файл: скопировал файл новой задачи и подставил нужный идентификатор, а потом убрал чат штатно — сначала «Архивировать», затем «Удалить» в приложении. Переустановка и чистая папка .codex не помогли.

Отсюда два правила. Чаты удаляйте только из интерфейса, а не в папке сессий. Перед любыми опытами с чистым профилем сохраните копию папки .codex (в Windows — %USERPROFILE%\.codex).

Codex Web и «Unable to determine project root»: обхода пока нет

Две ошибки в облачных задачах Codex Web сейчас без рабочего обхода:

• Unable to determine project root for task — с 30 сентября по 4 октября 2026 года, у пользователей Plus в браузерах на Windows и macOS (#49497, #50178);
• a managed thread must retain its original environment — с 12 по 16 октября 2026 года, в приложении для компьютера, в браузере и на Android (#53459, #54395).

Не помогли: жёсткое обновление страницы, правка и повторная публикация окружения, создание окружения заново. Поддержка OpenAI предложила одному из пользователей создать новое окружение — создание задачи у него зависло на 24 минуты. Авторы отчётов просят не сбрасывать и не удалять окружение, пока работа из задачи не сохранена в другом месте. Для Unable to determine project root один пользователь заметил, что dot всё ещё может передавать сообщения в эту сессию.

Лимиты: 1 048 576 символов текста и 4 МиБ на сообщение

Input exceeds the maximum length of 1048576 characters. — в открытом коде app-server текст одного сообщения ограничен 1 048 576 символами. Если вставили огромный журнал или файл целиком, сократите его или дайте агенту путь к файлу.

decoded message length too large: found 8255971 bytes, the limit is: 4194304 bytes — сообщение больше 4 МиБ (4 194 304 байта). В единственном отчёте (#52649) так вышло, когда разом отправили много пометок из встроенного браузера. Предложение отправлять их меньшими порциями или заменить обрезанным скриншотом со списком замечаний никто пока не проверил.

Что OpenAI сказала об ошибке Error submitting message

По состоянию на 16 октября 2026 года единственное заявление сотрудника OpenAI — сообщение от 13 сентября в #44781 об очереди сообщений: исправление готово и войдёт в следующий релиз, без номера версии. В журнале изменений и справке OpenAI нет записи, которая называла бы эту ошибку или сборку с исправлением. В X сотрудники Codex и аккаунт @OpenAIDevs о ней тоже не писали. Причины ошибок AbsolutePathBuf, agent loop died, EPERM, no client found и ошибок Codex Web OpenAI публично не объясняла.

Что отправить в OpenAI, если решения нет

1. Обратная связь из приложения. Введите / в поле ввода и выберите отправку отзыва. Если сделать это в проблемном чате, можно приложить сессию; после отправки вы получите идентификатор сессии, его стоит добавить в обсуждение на GitHub.
2. Точный текст второй строки. Скопируйте его целиком — по нему ищут дубли.
3. Версии. Номер сборки приложения или расширения, ОС, где работаете (приложение, VS Code, Web). Приложение ChatGPT и Codex CLI могут включать разные версии Codex: версию CLI показывает codex --version, версию в приложении на macOS — /Applications/Codex.app/Contents/Resources/codex --version.
4. Журналы. На macOS журналы приложения лежат в ~/Library/Logs/com.openai.codex/ в подпапках по году, месяцу и дню. Перед отправкой просмотрите их и уберите ключи, токены и другие конфиденциальные данные — об этом просит и OpenAI.
5. Существующее обсуждение. Если ваша строка есть в таблице выше, добавьте сведения в указанное обсуждение на GitHub, а не открывайте новое.

Вопросы о том, почему Codex не отправляет сообщения

Почему Codex не работает и не отправляет сообщения?

Если появляется «Ошибка при отправке сообщения», причину называет вторая строка: сбой очереди, тайм-аут, проблема с разрешениями задачи на Windows, ошибка облачного окружения и так далее. Начните с нового короткого чата: если он работает, дело в конкретном чате, если нет — полностью перезапустите приложение. Ошибки 429 и 401 устроены иначе и разобраны в статье «Ошибка Codex exceeded retry limit 429, 401 и Stream Disconnected».

Поможет ли обновление Codex?

Не обязательно. При agent loop died одному пользователю помогло обновление приложения. При сбое очереди в сентябре и при AbsolutePathBuf обновления и переустановка не помогали, а сборка с исправлением OpenAI не названа. Обновиться стоит, но не рассчитывайте, что этого хватит. Перед обновлением скопируйте неотправленный текст.

Пропадёт ли чат после перезапуска Codex?

В отчётах после полного выхода и повторного запуска чаты сохранялись. Один из авторов прямо пишет, что потери данных не было, другой — что обновление не уничтожило «мёртвый» чат. Гарантии никто не даёт: копируйте важный текст заранее и не удаляйте файлы в ~/.codex/sessions вручную. Для облачных задач Codex Web не сбрасывайте окружение, пока работа не сохранена.

Почему одно и то же сообщение отправилось дважды?

Скорее всего, первая отправка на самом деле дошла, хотя интерфейс показал ошибку, а затем вы нажали «Повторить». Такое описано в отчётах о сбое очереди и об ошибке EPERM в Windows, а в журналах тайм-аута виден тот же механизм: ответ сервера приходит после того, как клиент перестал ждать. Остановите лишний ход и проверьте git status, чтобы агент не сделал одни и те же изменения дважды.