OpenClaw 2026.10.2: что проверить перед апгрейдом

Коротко

Первый апдейт с 2026.10.1 завершается без ошибок и откатов на Windows, на клонированных ФС и там, где OpenClaw ставит обновление своим Node, а не системным.
Doctor больше не стопорится на остаточных legacy-импортах, устаревших локах Gateway, reindex-локах и списках разрешённых отправителей удалённых аккаунтов.
Списки разрешённых отправителей для аккаунтов канала, которых больше нет в обнаружении, уходят в .migrated с предупреждением, исходные байты остаются для восстановления.
Граница: повреждённые списки разрешённых отправителей настроенных аккаунтов и неоднозначные идентичности по-прежнему требуют ручной починки до миграции.

Сверено с документацией OpenClaw 2026.10.2, 12 октября 2026.

Заметки к релизу перечисляют семь правок для Windows, клонированных файловых систем и установок со своим Node от OpenClaw. Раньше они стопорили первый апдейт с 2026.10.1 или откатывались. Doctor, который раньше спотыкался на остаточных legacy-импортах, устаревших локах Gateway, медленной инспекции состояния и списках разрешённых отправителей удалённых аккаунтов каналов, теперь на них не останавливается.

Что чинит 2026.10.2 в первом апдейте

Список выделяет в первом апдейте с 2026.10.1 семь PR: #168849, #169031, #165233, #166530, #168968, #164677, #165257. Успешные in-place обновления больше не заканчиваются ошибкой. В разделе Changes две точечные правки: финальный отчёт об успехе обновления и подавленные каналы идут как warning (#169037). npm dist-tag больше не валит уже проверенные релиз-кандидаты (#168836).

Doctor: архив и живые данные

Изменения страницы cli/doctor/state-migrations.md явно описывают поведение для списков разрешённых отправителей каналов. Если именованный аккаунт канала больше не появляется при обнаружении аккаунтов, Doctor переносит его credentials/<channel>-<account>-allowFrom.json в существующий архив .migrated (с числовым суффиксом при занятом имени), печатает оба пути как предупреждение и идёт к следующей миграции. Исходные байты лежат в архиве и не приписываются ни одному живому аккаунту.

Тот же текст страницы добавляет правила для каталога агентов. Инспекция выбирает openclaw-agent.sqlite и зарезервированное имя incognito-openclaw-agent.sqlite по владельцу пути агента. Пользовательские имена БД требуют настроенного хранилища, записи в реестре или зафиксированного пути удаления. Состояние инкогнито-режима остаётся в памяти. Существующий файл на зарезервированном пути считается коллизией для восстановления, его не заменяют и не подключают как хранилище в памяти. Соседние reindex-локи, копии состояния и SQLite-сайдкары не считаются отдельными хранилищами. Ранее зафиксированные удержания coordination-файлов остаются в recovery-копиях, но не дают предупреждений о задержанном агенте.

Изменения в cli/doctor/sqlite-maintenance.md касаются записей о восстановлении. Если такая запись изменилась, Doctor оставляет оригиналы этой цели на месте с предупреждением и не останавливает остальные починки Doctor и плагинов после сессии. Нечитаемая история восстановления больше не требует пустой SQLite-цели. Doctor сверяет каждую сессию, сохраняет её метаданные и генерацию, проверяет существующий контент транскрипта и импортирует новую историю через обычный поэтапный импортёр. Подтверждённые оригиналы уезжают в архив восстановления с записями отчёта.

Граница: что всё ещё требует рук

Документ прямо называет две категории, которые Doctor чинить не будет: повреждённые списки разрешённых отправителей для настроенных аккаунтов и неоднозначные идентичности аккаунтов. Они стопорят миграцию и требуют ручной починки до того, как остальные шаги смогут продолжиться. Doctor, запущенный при обновлении, ведёт себя так же. Не путайте их с автоматическим архивированием. Повреждённый список разрешённых отправителей аккаунта, который сейчас настроен, остаётся блокером. Список разрешённых отправителей аккаунта, которого больше нет в обнаружении, уезжает в .migrated с предупреждением.

Команды обновления и распутывания

Из раздела про восстановление после апдейта такая последовательность:

openclaw status --all
openclaw update status --json
openclaw gateway status --deep
openclaw doctor --fix
openclaw gateway restart

В документе про обслуживание SQLite openclaw backup create --verify стоит первым шагом перед openclaw doctor --state-sqlite compact --json.

Что проверить при обновлении

После установки 2026.10.2 выполни openclaw status --all и openclaw update status --json. Завершённый апдейт с предупреждением по подавленным каналам идёт через warning, а не через failure.
Устрани застрявшие миграции и устаревшие локи через openclaw doctor --fix. Не прерывай его: при прерывании уже принятые батчи остаются каноничными, оставшиеся придётся прогонять заново.
Проверь, не появились ли предупреждения про credentials/<channel>-<account>-allowFrom.json в .migrated. Список разрешённых отправителей уехал в архив автоматически, исходные байты сохранены для восстановления.
Если в логах остались блоки на повреждённый список разрешённых отправителей или неоднозначную идентичность аккаунта, исправь эти два класса вручную до повторного doctor --fix. 2026.10.2 их не чинит.
Перезапусти Gateway и убедись, что проверка готовности проходит: openclaw gateway restart, затем openclaw gateway status --deep. Если старт падает с prepared model runtime publication (...) timed out на этапе ambient credentials и у вас Claude CLI, выполни claude auth status --json от пользователя Gateway и с тем же окружением.