2026 OpenClaw sessions_spawn и сессии песочницы: диагностика на Mac cloud

Шлюз слушает, но падают дочерние процессы или шаги в песочнице — чаще из‑за рабочего каталога, пользователя, прав или политики. См. первый деплой, типичные ошибки, укрепление продакшена.

Диагностика OpenClaw на Mac cloud

Содержание

1. Три паттерна: шлюз работает — не значит, что spawn здоров

После первого деплоя и типичных ошибок главная путаница — процесс жив, а сессии или команды в песочнице падают. Строки с sessions_spawn относятся к другому слою, чем прослушивание порта 18789. Вместе с укреплением продакшена проще держать политику и пути в одной таблице.

  1. Сдвиг cwd: интерактивный SSH в ~/project, а launchd стартует из / или чужого home. Дочерние процессы наследуют пустой или нес writable cwd. APFS по умолчанию без учёта регистра — пути с Linux дают скрытые коллизии.
  2. UID и владелец: кэш или репозиторий с чужим владельцем даёт EACCES в песочнице. Ручной запуск и launchd идут под разными пользователями.
  3. Политика песочницы: жёсткие egress/подпроцессы блокируют легитимную автоматизацию, хотя dashboard отвечает.

Метрика: после холодного старта только через launchd измерьте время до первого успешного spawn. Если SSH всё чинит — проблема в наследовании среды или WorkingDirectory.

2. Таблица: сессия / шлюз / порт

Колонка «Обычно нет» снижает ложные треки: chmod редко лечит Unauthorized; песочница не поможет, если процесс падает до слоя сессий.

СимптомСначалаПроверкаОбычно нет
doctor ок, spawn на задачахСессия/песочница/путьминимальное репро, проверить cwdтолько порт 18789
Unauthorized в клиентеАутентификация шлюзаopenclaw config get для gateway.authchmod (кроме чтения token-файла)
шлюз сразу падаетПорт/зависимостиlsof -i :18789, память, Nodeлогика песочницы до listen
падают только типы задачПолитика/allowlistвременно ослабить и сравнитьсначала плагин канала
после обновленияМиграция ключейструктурный diff openclaw.json«случайная» нестабильность

3. Пять шагов плюс регрессия

Тот же Unix-пользователь, что и в продакшене.

  1. Вход: задокументировать launchd или ручной старт; перед переключением openclaw gateway stop и lsof -i :18789.
  2. Минимальное репро: крошечный пример сессии в prod-cwd. Расхождение SSH vs launchd указывает на env.
  3. Владение: ls -le и ACL; при необходимости пересоздать state-каталог с одним владельцем.
  4. Логи: отдельно логи шлюза и unified log (пример ниже).
  5. Diff: после апгрейда сравнить sandbox/env блоки.
  6. Регрессия: doctor → минимальная сессия → реальная нагрузка → суточный soak.
whoami id launchctl print gui/$(id -u) | head -n 20 log show --style syslog --last 30m --predicate 'process == "node" OR eventMessage CONTAINS "sandbox"' | tail -n 80
Важно: в plist launchd должен быть WorkingDirectory — иначе cwd детей пустой.

На Mac cloud фиксируйте вход+cwd+владельца в том же runbook, что и CI.

4. Измеримые сигналы

① PATH и HOME у launchd и login shell различаются. ② APFS и смешанные пути Linux/macOS. ③ Память: кратковременный RSS >2 ГиБ может дать OOM (код 137), похожий на spawn-ошибку. ④ Два шлюза на одном state — гонки. ⑤ Аудит: каждая новая строгая политика песочницы — строка в журнале изменений.

5. К нативной базе сессий macOS

Контейнеры добавляют тома и сигналы — два слоя отладки. Ноутбуки спят и меняют пути. Универсальные Linux VPS редко описывают launchd и владение файлами.

Для стабильного UID, записываемых каталогов состояния и 24/7 выделенный Mac cloud проще, чем стек абстракций.

Аренда VPSMAC M4 с версионируемыми plist, фиксированным пользователем и SLO на p95 первого успешного spawn после перезагрузки — не только HTTP на 18789.

6. FAQ

Падает только spawn, шлюз жив

Сначала cwd, пользователь, владелец; сравнить pwd с WorkingDirectory в plist; diff env SSH и launchd.

Только после обновления

Переименованные ключи, более строгие умолчания — diff openclaw.json и таблица OPENCLAW_* из релиз-нот.

Несколько инстансов

Не делить один каталог состояния; разделять корни конфигов, порты или хосты.