Codex: Cannot serialize value в режиме Worktree — что делать

Cannot serialize value в Codex: сбой сборки 26.1016 при старте Worktree

Вы открыли новый чат с включённым New worktree, отправили первое сообщение и получили:

Error starting chat
Cannot serialize value: (couldn't stringify value)

Репозиторий, текст запроса и сеть здесь ни при чём. По сообщениям пользователей в issue #55744, так ведёт себя сборка настольного приложения 26.1016.51333 (build 21161) на macOS, Windows и Linux: падает только запуск нового чата в режиме Worktree, а то же сообщение в режиме Local уходит без ошибок. Заголовок баннера может быть переведён на язык интерфейса, вторая строка остаётся английской.

Что делать прямо сейчас:

1. Выключите New worktree (выберите Local) под полем ввода и отправьте сообщение ещё раз. Перезапускать приложение не нужно.
2. Если агенту нужна отдельная копия репозитория, перенесите чат в Worktree через Hand off, попросите Codex из работающего чата открыть новый чат в worktree или создайте worktree сами через git worktree add. Чем эти и другие обходы различаются и насколько каждый проверен — в разделе об изоляции ниже.
3. Не тратьте время на перезапуск, переустановку и смену ветки: пользователи пробовали, ошибка остаётся.

По состоянию на 22 октября 2026 года issue открыт, сотрудники OpenAI в нём не отвечали, а в официальном журнале изменений нет ни сборки 26.1016, ни исправления.

С 9 июля 2026 года Codex входит в настольное приложение ChatGPT, поэтому одну и ту же сборку называют и Codex desktop, и ChatGPT desktop 26.1016.51333. Подписи Worktree, Local, New worktree и Hand off приведены так, как они названы в документации; в интерфейсе на другом языке они могут выглядеть иначе.

Та же ли это ошибка: версия 26.1016, режим Worktree и работающий Local

Это тот самый сбой, если сходятся три признака.

• Версия 26.1016.51333. Её показывает окно сведений о приложении (About). В Windows установленный пакет называется OpenAI.Codex_26.1016.6573.0_x64: номер другой, но сборка та же, поэтому вы можете увидеть любое из двух чисел.
• Ошибка появляется после отправки первого сообщения в новом чате с Worktree, а не при нажатии New chat. Вложения не нужны: в исходном отчёте сбой воспроизводится на простом «привет».
• Тот же текст в новом чате Local отправляется. Это самый быстрый способ отличить эту ошибку от остальных.

Проекты на удалённых хостах по SSH затронуты так же: пользователи с Windows и macOS сообщают, что для проекта на удалённом хосте чат Worktree падает, а чат в существующей копии работает.

Если признаки не сходятся, это другая проблема:

• Падает и чат в Local. Значит, ломается не старт Worktree, и обходные пути ниже не помогут.
• Ошибка в расширении Codex для VS Code. В сентябре 2026 года там была своя проблема сериализации с баннером «Error creating chat»; это другой продукт и другой случай.
• Баннер «Error submitting message» с другой второй строкой — отдельная группа ошибок, причину ищут по этой второй строке.
• Приложение вообще не запускается: см. Failed to start codex app-server в Windows: ошибки и что делать.
• Чат бесконечно переподключается: см. Codex постоянно переподключается: сохраните задачу и найдите причину.
• Запуск обрывается тайм-аутом загрузки конфигурации: см. Codex не загрузил cloud config bundle за 15 секунд: что проверить.

Отправить сообщение сейчас: выключите New worktree и выберите Local

1. В окне нового чата найдите выбор режима под полем ввода. Часть пользователей нашла переключатель в настройках нового чата под значком шестерёнки.
2. Выключите New worktree или выберите Local.
3. Отправьте сообщение снова. Многие пользователи на всех трёх ОС подтверждают, что после этого чат запускается, перезапуск не требуется.

Цена у этого способа одна, но существенная: в Local чат работает в вашей обычной копии проекта, и агент правит файлы прямо в ней. Изоляция, ради которой включают Worktree, пропадает. Перед отправкой стоит закоммитить или убрать в git stash собственные незакоммиченные правки: тогда изменения агента будут видны отдельным диффом, и их легко откатить.

Если в Local хочется ограничить, что агент может менять, настройте песочницу: Песочница Codex и config.toml: границы, подтверждения и сеть.

Как сохранить изоляцию worktree, пока исправления нет

Сломан только один путь — запуск нового чата в Worktree с обычным текстом из поля ввода. Сами worktree на затронутых машинах создаются, поэтому изоляцию можно получить в обход.

Как выбрать:

• macOS, нужна изоляция для этой задачи — попросите Codex открыть новый чат в worktree (две полные проверки, в том числе на локальном проекте) или перенесите текущий чат через Hand off (одна проверка, зато чат и история остаются вместе).
• Windows или Linux — попросите Codex подключить worktree к текущему чату (проверено и на Windows) или создайте worktree сами. Для Hand off и для просьбы открыть новый чат в worktree на этих ОС сообщений нет, ни удачных, ни неудачных.
• Проект на удалённом хосте по SSH — просьба открыть новый чат в worktree проверена и на удалённом Linux-проекте (клиент на macOS); запасной вариант — свой git worktree add на хосте.
• Нужна долгоживущая копия — свой git worktree add: это обычная команда Git, и она работает независимо от приложения.
• Хочется оставить привычную кнопку Worktree — свой промпт /prompts:worktree-start, но только как временная мера: функция устарела, а подтверждение одно.

Hand off: первое сообщение в Local, затем перенос в Worktree

1. Начните новый чат в режиме Local. Чтобы агент не успел ничего поменять в вашей копии, первым сообщением можно попросить его только подтвердить задачу и ждать.
2. Когда ответ придёт, нажмите Hand off в заголовке чата и выберите Worktree.
3. Убедитесь, что чат переключился и рабочая папка — новый управляемый worktree. По умолчанию такие копии лежат в $CODEX_HOME/worktrees; путь меняется в Settings > Worktrees > Worktree root.

Этот путь проверил один пользователь на macOS: создание worktree, перенос изменений и переключение чата прошли успешно, история сохранилась. По документации Hand off переносит и чат, и код, поэтому незакоммиченные правки из вашей копии уедут вместе с чатом. Файлы, перечисленные в .gitignore (например, .env), не переносятся, если их не указать в файле .worktreeinclude в корне репозитория.

Управляемый worktree создаётся в состоянии detached HEAD. Если результат нужен в виде ветки, используйте Create branch here в заголовке чата. По умолчанию приложение хранит 15 последних управляемых worktree, более старые удаляет.

Попросить Codex открыть новый чат проекта в worktree

Из любого работающего чата попросите Codex обычными словами начать в этом проекте новый чат в worktree и передать ему задачу. Например:

Начни новый чат в проекте <имя проекта> в режиме worktree и передай ему задачу: <ваш запрос>.

Агент создаёт новый чат своими встроенными средствами, название внутреннего инструмента знать не нужно. Если агент ответит, что так не умеет, переходите к другим путям. В отличие от подключения worktree к текущему чату (следующий способ), здесь сам новый чат работает внутри worktree, а не рядом с ним.

Этот путь до конца прошли двое пользователей, оба с клиентом на macOS: с проектом на удалённом Linux-хосте и с локальным Git-проектом. В обоих случаях новый чат запустился и ответил, а проверка показала, что он работает в отдельном чистом worktree в состоянии detached HEAD. С клиентов на Windows и Linux сообщений пока нет, поэтому после запуска проверьте то же самое:

pwd             # путь должен вести в папку worktree, а не в вашу копию
git status      # в чистом worktree изменений нет, HEAD отсоединён

Для удалённого проекта хост должен быть в сети: неудачная попытка при выключенном хосте к этой ошибке не относится.

Попросить Codex подключить worktree к текущему Local-чату

В работающем Local-чате того же проекта отправьте запрос. Проверенная формулировка — английская:

Create and attach a managed worktree for this task, then do all work in that checkout.

Агент вызывает встроенный инструмент создания worktree, и новая копия подключается к чату. Так сделал пользователь на macOS, а пользователь на Windows прошёл этот путь до конца.

Главный подвох: сам чат остаётся в исходной копии. Агент получает путь к новому worktree, но в следующих запросах его надо явно держать в этой папке — например, напоминать путь и просить выполнять git status именно там. Зависимости и сервисы в новой копии никто не готовил: установите их сами, прежде чем запускать тесты.

Свой промпт /prompts:worktree-start: старт в Worktree как раньше

Этот обход оставляет обычный запуск чата в режиме Worktree. На компьютере, где запущено приложение (для удалённого проекта — на клиенте, а не на хосте), создайте файл пользовательского промпта:

mkdir -p ~/.codex/prompts
printf '%s\n' 'Work in the isolated worktree created for this chat. Follow the request below.' > ~/.codex/prompts/worktree-start.md

Затем перезагрузите окно приложения, чтобы промпт подхватился, оставьте выбранным Worktree и отправьте запрос через этот промпт:

/prompts:worktree-start Reply OK; do not change any files.

Дальше задачи можно отправлять так же: /prompts:worktree-start, затем текст запроса. Один пользователь подтвердил, что так чат Worktree запускается (клиент на macOS, проект на удалённом Mac, сборка 26.1016.51333). По его разбору кода приложения, при раскрытии промпта текст запроса меняется, и приложение не кладёт в историю документ редактора — то самое значение, на котором падает упаковка.

Это временная мера. OpenAI объявила пользовательские промпты устаревшими 22 января 2026 года в пользу навыков (skills), см. журнал изменений. В сборке 26.1016 они у этого пользователя ещё работали, но любое обновление может их убрать. Для Windows путь к папке промптов в отчётах не встречается.

Свой git worktree add и отдельный проект в Local

Создайте копию командой Git из корня репозитория:

git worktree add ../app-fix -b fix/x
cp .env ../app-fix/    # игнорируемые файлы сами не копируются

Затем добавьте папку ../app-fix в Codex как отдельный проект и начните в нём чат в режиме Local. Для приложения это обычная папка, поэтому сломанный старт Worktree не задействуется. Ручное создание worktree работает на затронутых машинах, в том числе на удалённом Linux-хосте.

Что учесть:

• .worktreeinclude действует только на управляемые worktree приложения, а не на созданные из командной строки, поэтому .env и другие игнорируемые файлы копируйте вручную.
• Git не даёт держать одну ветку в двух worktree одновременно: пока fix/x занята в ../app-fix, в основной копии её не переключить.
• Когда работа закончена, уберите копию и ветку:

git worktree remove ../app-fix
git branch -d fix/x

Постоянный worktree: официальная функция, против этой ошибки не проверена

Постоянный worktree создаётся из меню «три точки» у проекта в боковой панели. Он появляется как отдельный проект, автоматически не удаляется, и в нём можно вести несколько чатов. Сообщений о том, что кто-то пробовал его против этой ошибки, нет. Если решите попробовать, начинайте чаты в таком проекте в режиме Local: ломается именно старт чата в режиме Worktree, а Local-чат в отдельной копии этот шаг обходит — но это вывод, а не проверка. Не сработало — переходите к собственному git worktree add.

Почему не помогают перезапуск, переустановка и другая ветка

Пользователи перепробовали очевидное, и ничего из этого ошибку не убрало:

• перезапуск приложения и полный выход, а также перезагрузку компьютера и повторный вход в аккаунт;
• переустановку приложения на macOS; приложение проходит проверку подписи, то есть установка не повреждена;
• повторный выбор начальной ветки и восстановление настроек проекта;
• полный доступ к диску (Full Disk Access) для приложения на macOS: после этого в журнале та же TypeError и нет ошибок доступа к файлам (EPERM/EACCES), так что права macOS здесь ни при чём;
• другой текст сообщения.

Причина в коде самой сборки. Перед отправкой приложение упаковывает запрос (сериализует его), чтобы передать собственному внутреннему процессу. В журналах приложения сбой выглядит как [Composer] submit failed с errorName=TypeError и mode=worktree, и происходит он ещё до создания worktree, на запросе managedWorktrees.pending.create. С репозиторием всё в порядке: git worktree list работает.

Двое пользователей, на Windows и на macOS, подключили отладчик и поймали значение, которое отвергает упаковщик: openingPromptForHistory.document.attrs. Это служебные атрибуты первого сообщения из редактора — объект без прототипа с ключами start и end. Упаковщик принимает только обычные объекты. Когда он пытается превратить отвергнутое значение в строку для текста ошибки, это тоже не удаётся, поэтому вместо имени поля вы видите (couldn't stringify value).

Отсюда понятно, почему не помогает ничего из списка выше. Редактор создаёт такой объект для любого текста, поэтому формулировка не важна; исключение — раскрытие своего промпта, описанное выше, когда документ редактора в историю не попадает. Сломанный код поставляется в самой сборке, и переустановка той же версии возвращает его на место. Ветка и настройки проекта в этом шаге не участвуют.

Это диагноз сообщества, OpenAI его не подтверждала. Временный патч в памяти, который приводил это одно поле к обычному объекту, позволил запустить чат Worktree и тем подтвердил причину, но исчезал после перезапуска. Править файлы приложения или внедрять код через отладчик не стоит: приложение подписано, такие изменения не поддерживаются. Надёжный выход — официальная сборка с исправлением.

Похоже на регрессию: в журналах Windows 20 октября, на прежнем пакете 26.1013, чаты Worktree создавались без ошибок, а первая такая ошибка появилась 21 октября на новом пакете. Но более старую сборку напрямую никто не проверял, так что это вывод, а не доказанный факт.

Когда исправят Cannot serialize value: статус на 22 октября 2026 года

Сроков исправления нет. По состоянию на 22 октября 2026 года:

• #55744 открыт, метки bug, app и session, 63 комментария и 145 реакций; ответа сотрудников OpenAI в теме нет;
• открыты и отдельные отчёты для Linux (#55823) и Windows (#55827);
• последняя запись о приложении Codex в журнале изменений — 26.1007 от 8 октября; сборки 26.1016 и исправления там нет.

Как понять, что исправление вышло:

1. После обновления номер в окне About отличается от 26.1016.51333 (в Windows номер пакета — от 26.1016.6573.0).
2. Создайте один новый чат с включённым New worktree и отправьте короткое сообщение. Чат запустился — можно возвращаться к привычной схеме. Снова баннер — оставайтесь на обходном пути.
3. Копии, созданные вручную через git worktree add, доведите до конца и удалите, когда они больше не нужны.

Если хотите, чтобы ваш случай учли, отправьте отзыв из приложения (Feedback или команда /feedback): вы получите ID. Напишите его в #55744 вместе с версией приложения, ОС и режимом чата (Worktree или Local) — так поступают участники обсуждения.

Вопросы о Cannot serialize value: CLI, iPhone, VS Code и откат

Работает ли Codex CLI, пока в приложении эта ошибка?

По одному сообщению — да, codex-cli работает. Это ожидаемо: у CLI нет поля ввода настольного приложения, через которое проходит сбойный запрос. Но подтверждение пока единственное.

Можно ли запустить чат Worktree с iPhone?

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

Затронуто ли расширение Codex для VS Code ошибкой Cannot serialize value?

Неизвестно: в обсуждении сборки 26.1016 сообщений о расширении нет. Сентябрьская ошибка «Error creating chat» в VS Code — отдельная история, и связывать её с этой нет оснований.

Можно ли откатиться на 26.1013?

Официального способа вернуться к прежней сборке нет. Один пользователь собирался откатиться на 26.1013.40934, но к моменту сообщения этого не сделал и результат не проверил. Режим Local и пути с изоляцией выше надёжнее.

Не повреждён ли репозиторий после ошибки Cannot serialize value?

Нет. Сбой происходит до того, как приложение начинает создавать worktree, поэтому до репозитория запрос не доходит. У пользователей, разбиравших журналы, git worktree list работал, и проблем в самих репозиториях не нашлось.