2026 OpenClaw Agent: песочница (Sandbox), Docker-образ, docker.user и права томов, «нет утилиты» внутри и OOM/137

Почему песочница превращается в «у меня локально есть, а в контейнере — нет»

Корневая причина — граница процесса:

1. Корневая ФС не равна хосту: песочница — отдельный образ. То, что вы brew install на хосте, не окажется в PATH песочницы без слоя в образе или маунта.
2. Рабочая зона в bind: хозяин 501:20, процесс 1000:1000 в контейнере — и получаете Permission denied / EROFS.
3. Ещё одна зона безопасности: даже если у Gateway сеть, DNS, выходы и набор инструментов в песочнице планируются отдельно, это не то же, что «зашли по SSH и поставили на хосте».

Сводка: Docker-песочница, SSH, без песочницы

Конфиг: agents.defaults.sandbox.docker и sandbox-setup.sh

Два слоя: какой движок песочницы (образ/рантайм) и откуда образ. В репозитории обычно scripts/sandbox-setup.sh для сборки/скачивания образа, который видит docker на хосте. agents.defaults.sandbox.docker.image — тот, на котором крутится сессия. Расхождение: Gateway думает, что песочница включена, а docker run даёт manifest not found или pull access denied.

docker.user и маунт OPENCLAW_HOME: ориентир по симптому, а не chmod 777 подряд

Рекомендуемый порядок:

• на хосте: каталог workspace (владелец, группа) и фактическое с какой учётки крутится Gateway;
• в конфиге: docker.user как дописываемый UID:GID (по документации; в версиях вложенность под sandbox.docker);
• если нельзя chown всего репозитория — подкаталог для маунта, а не весь диск.

На Linux и на удалённом Mac именованные/ bind-тома, метки SELinux усиливают эффект «в Compose смотрелось нормально, внутри — нет». Берите первую строку I/O-ошибки из логов Gateway/песочницы, а не случайные оживления в чате.

Четыре вопроса, если на хосте команда есть, в песочнице — нет

1. Бинарник в каталоге PATH из образа? docker exec + command -v важнее догадок.
2. Нет ли библиотеки/интерпретатора (Node/Python) нужной минор-версии в образе?
3. Нужен ли read-only bind (например, ~/.cache)? Логичнее кэш в образе/общем слое, а не дырка с хоста.
4. Та же сетевая политика, что и у Gateway, может требовать HTTP(S)_PROXY; сеть часто сыпется как «command not found».

OOM и exit 137: «убили» и «мало памяти»

137 = 128 + 9 (SIGKILL) часто связывают с OOM, но встречается и docker kill вручную, и лимит по памяти cgroup. В разборе: docker build vs docker run, параллельные сборки в Docker Desktop/VM, на удалённом Mac — реальная свободная RAM и swap, а не лимит одного контейнера. Отдельно: код 1/2 + много Cannot allocate memory в одном пакете с кратким запасом RAM/темп-диском.

При OOM на сборке: снизить параллелизм, многостадийная сборка, больше памяти у VM, выделенный удалённый Mac с запасом RAM как стабильный фундамент — другое, чем «случайно влезли IDE+локальная LLM+Docker на ноутбуке». Общее хранилище: inode, мелкие файлы могут «под OOM» подвисать — сегменты томов, политика уборки.

Шесть шагов: от нуля к устойчивому кругу в песочнице

1. Docker/Compose + Gateway здоровы, см. триаж Gateway и doctor.
2. Запустить sandbox-setup, имя и id образа встык с конфигом.
3. на тестовом workspace включить песочницу: маленький файл, большой каталог, собрать ошибки прав.
4. A/B docker.user + маунты — по одной переменной, с diff, чтобы не потерять откат.
5. средняя по тяжести сборка, смотреть память, фиксировать 137.
6. runbook в вики: минимум воспроизведения, кусок лога, границы, когда песочницу нельзя выключать.

{
  "agents": {
    "defaults": {
      "sandbox": { "mode": "docker" },
      "docker": { "user": "1000:1000" }
    }
  }
}
// Вынесено в sandbox.docker в вашей сборке — проверяйте doctor/доку

Три пункта в закладку (ревью, ёмкость)

• 137 и 128+: в тикете писать и docker events/движок, и memory pressure — не путать прикладной OOM с docker build в параллель.
• user namespace, UID на bind: chown -R 1000:1000 в одной папке проекта и «сдвиг домашки» — разные риски; тикет и откат.
• холодный старт песочницы — крупные слои, первый pip индекса, скачивания без кэш-слоя: «один раз сработало» ≠ «сто раз»; цифру первого старта в таблицу ёмкости.

Почему «временно Docker+большая модель+Xcode на ноутбуке» редко тянет корпоративный тон песочницы

Как правило, проигрыш по одновременным пикам RAM и I/O и воспроизводимой среде. Когда в проде 7×24 Gateway+песочница нужны, а стабильных инструментов выделенного Apple Silicon в облаке, диск- и лог-регламента, предсказуемой аренды больше, облачные Mac MACCOME лучше бьют в длительно живущий OpenClaw — вы меньше воюете с локальной случайностью и больше отдаёте время цепочке и релизу.