Безопасность · OpenClaw

OpenClaw 2026.9.6 и новее: захват плагина блокирует Gateway на минуты

Если у вас есть внешние или workspace-плагины с большим деревом зависимостей, узнайте, как отличить эту регрессию и что делать до патча.

· 3 мин чтения

Коротко

  • Регрессия появилась в OpenClaw 2026.9.6 (#144252): синхронный захват плагина копирует его пакет и дерево зависимостей на главном потоке и блокирует event loop Gateway на минуты.
  • Под ударом инсталляции с большими внешними или workspace-плагинами. Частичные смягчения слили в 10.x, но центральная проблема синхронной работы остаётся.
  • Снимайте трассировку старта через OPENCLAW_GATEWAY_STARTUP_TRACE=1 и смотрите фазу plugins.runtime-post-bind. Обходы до патча: 2026.10.5, отключение тяжёлых внешних плагинов и gateway.reload.mode: "off".

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

В трекере #160959 регресс уже отслеживают, частичные смягчения слили в 10.x, но центральная проблема синхронной работы на главном потоке остаётся. TCP-соединения принимаются, но /healthz, WebSocket RPC и опрос каналов не отвечают минутами.

Что именно ломается

В 2026.9.6 в #144252 добавили capturePluginGenerationArtifact (src/plugins/plugin-generation-artifact.ts). Перед загрузкой плагина Gateway копирует его пакет и обходит зависимости через capturePluginDependencies → linkDependency → copyPackage → copy.

Когда у плагина не задан entryFile, copyPackage копирует корень целиком, а потом рекурсивно всё дерево зависимостей. Всё это происходит синхронно в основном потоке. Пока идёт захват, Gateway принимает TCP, но не отвечает ни на /healthz, ни на WebSocket RPC, ни на опрос каналов.

Цифры из issue 160959

Изолированный repro на main 4d4d99d с синтетическим плагином на 878 MB: Gateway стоит 219 с до начала прослушивания и ещё 168 с после. В логах: prepared model runtime startup degraded after 120000ms (workspace plugins; agent main).

Продакшен 2026.9.6, плагин 134 MB с node_modules 1.5 GB на 221 пакете (Bun global install). Процесс стартует в T+0, http server listening появляется на T+2m20s, а /healthz отвечает только к T+7m. На одном из republish-ов event loop заблокирован на 124 с (eventLoopDelayMaxMs=124352). Telegram-опрос зависает, config.patch уходит в UNAVAILABLE через 125 с, и Gateway уходит в рестарт, который снова блокируется.

Стек в инспекторе один и тот же: realpathSync ← pluginNativeNamespaceMemberPath / resolvePreparedSource ← copy (recursive) ← materialize ← copyPackage ← linkDependency ← capturePluginDependencies ← captureDependencies ← materialize ← copyPackage ← capturePluginGenerationArtifact.

Как понять, что это ваш случай

2026.7.35 не задета, регрессия пришла именно с 2026.9.6.

На Windows 2026.10.3 профиль CPU обычной команды openclaw --help показал 95,3% времени внутри capturePluginGenerationArtifact на отрезке 282,5 с — захват тормозит и CLI. Среди системных вызовов лидируют lstat (141 с), realpath (37,9 с) и open (22,3 с) — это работа с метаданными файлов, а не контентное хеширование.

На Windows обнаружили связь с peer-ссылками. При «провисших» node_modules/openclaw часть плагинов уходит в карантин, при восстановленных ссылках они грузятся, но старт Gateway вырастает с 489,4 с до 1038,7 с.

Что уже слили и что осталось

Сводка бота clawsweeper от 2026-10-05: захват при старте и явной перезагрузке по-прежнему блокирует синхронно на текущем main; слитое исправление повторного использования prepared runtime не снимает центральной проблемы отзывчивости. #161267 (слито) решает только повторные захваты, не первичные. #164680 (слито) удешевляет Windows, но не убирает длинный первый захват.

По сводке бота, остаётся вынести capturePluginGenerationArtifact и подготовку к восстановлению из event loop в асинхронную стейджинг-зону внутри существующего жизненного цикла инстанса. Решение и границы требуют согласования с владельцем плагинного жизненного цикла.

Что делать сейчас

Пока issue открыт, помогают обходы из трекера. Обновитесь до 2026.10.5, там есть частичные смягчения. Временно выключите самые тяжёлые внешние плагины (openclaw plugins disable <id>). Если Gateway зависает после правок конфига, поставьте gateway.reload.mode: "off", чтобы горячая перезагрузка не запускала захват заново. Время захвата зависит от числа файлов, а не от объёма, поэтому плагины с огромным node_modules дороже всего.

Что проверить у себя

  1. Посмотрите, какие внешние плагины установлены и откуда: openclaw plugins inspect --all.
  2. Проверьте ошибки загрузки: openclaw plugins doctor.
  3. Запустите Gateway с OPENCLAW_GATEWAY_STARTUP_TRACE=1 и найдите фазу plugins.runtime-post-bind: если она длится минуты, а eventLoopMax почти равен её длительности, это ваш случай.