OpenClaw 2026.9.4: медленный stdio MCP-сервер валил Gateway с кодом 1

Коротко

На OpenClaw 2026.9.4 stdio MCP-сервер, не уложившийся в 30-секундный initialize, ронял весь Gateway с кодом 1 и сообщением service child cleanup identity lost.
Частичное сдерживание регрессии появилось в #144941. Полный репродьюсер с Feishu и холодным npx на main не закрыт.
Проверьте свой список mcp.servers, таймауты и поведение systemd/launchd при авторестарте.

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

На OpenClaw 2026.9.4 один stdio MCP-сервер, не уложившийся в 30-секундный initialize, ронял весь Gateway с кодом 1. Путь очистки выбрасывал необработанный отказ промиса с текстом service child cleanup identity lost: anchor channel closed without a matching closing receipt, и главный процесс завершался. Все каналы и сессии падали разом.

Как это выглядело на практике

Воспроизведение собрано на Ubuntu с npm-глобальной установкой OpenClaw 2026.9.4 под управлением systemd --user, с одним агентом main. В конфиге стоял stdio-сервер, чей холодный старт регулярно вылезал за 30 секунд.

"mcp": {
  "servers": {
    "zai-mcp-server": {
      "command": "npx",
      "args": ["-y", "@z_ai/mcp-server@latest"],
      "env": { "Z_AI_API_KEY": "***", "Z_AI_MODE": "ZHIPU" }
    }
  }
}

Входящее сообщение в Feishu в 19:44:58 запустило ход агента, инициализация сервера началась в 19:44:59. Через 30 секунд сработал таймаут, и в логе появилась цепочка из трёх событий.

19:45:29.597 [bundle-mcp] failed to start server "zai-mcp-server" (npx -y @z_ai/mcp-server@latest):
           MCP server "zai-mcp-server" timed out: did not complete initialize within 30s
           | MCP server connection timed out after 30000ms | The operation was aborted due to timeout | 23
19:45:29.603 [openclaw] Unhandled promise rejection: Error: service child cleanup identity lost:
           anchor channel closed without a matching closing receipt
           at loseIdentity (dist/child-CIJaNq5a.mjs:304:16)
           at finishPosixAuthority (dist/child-CIJaNq5a.mjs:358:5)
           at Socket.<anonymous> (dist/child-CIJaNq5a.mjs:494:5)
19:45:29.607 wrote stability bundle: ~/.openclaw/logs/stability/openclaw-stability-2026-09-11T11-45-29-604Z-9791-unhandled_rejection.json
19:45:29      Main process exited, code=exited, status=1/FAILURE

После рестарта тот же сервер инициализировался нормально, и прямой вызов инструмента через него в 20:13 прошёл штатно. Падение случалось только на пути обработки таймаута инициализации.

Почему один сервер роняет весь оркестратор

stdio MCP-сервер в mcp.servers запускается дочерним процессом. Если его initialize не уложился в 30 секунд, OpenClaw отменяет ожидание и идёт по пути очистки. В этом пути Client.connect отбрасывает промис, который возвращает client.close, и отказ теряется. Глобальный обработчик ловит его и завершает главный процесс. Падают каналы, активные сессии и агенты.

На macOS поверх этого срабатывает launchd. В одном из отчётов случилось 19 крэшей за утро, и каждый раз процесс перезапускался за ~10 секунд. Проверка по PID и времени работы обманывает. Нужен внешний сторож, который перезапускает сервис через launchctl kickstart -k.

Где сейчас ломается

Репродьюсер из Feishu и холодного npx на текущей main не воспроизводился. Та же сигнатура service child cleanup identity lost подтверждена для других путей: doctor --fix в Docker Compose и завершение работы в #144336. Сдерживающее исправление в #144941 описывает два сценария: contains SDK initialize-error cleanup rejection without certifying closure и contains SDK aborted cleanup rejection without certifying closure. В mcp-stdio-transport.test.ts эти тесты проходят на текущей main, всего 21 тест в файле. Открытый путь с void finishPosixAuthority(...) в src/process/supervisor/service-child-relay-host.ts этот PR не трогал.

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

Выгрузите текущий список MCP-серверов: openclaw mcp list. Проверьте stdio-серверы с холодным стартом дольше 30 секунд.
Для каждого stdio-сервера задайте connectionTimeoutMs явно и requestTimeoutMs по ситуации.
На хостах с systemd проверьте поведение сервиса после крэша: openclaw gateway status, openclaw status, openclaw logs --follow.
На macOS добавьте внешний сторож по статусу launchd: launchctl print gui/$UID/ai.openclaw.gateway | grep -E 'state|last exit|runs'.
Проверьте в ~/.openclaw/logs/stability/ свежие стабильностные пакеты: ls ~/.openclaw/logs/stability/ | tail -5, openclaw gateway stability --bundle latest.