agents.defaults.sandbox або agents.list[].sandbox). Якщо sandboxing вимкнено, інструменти запускаються на хості. Gateway залишається на хості; виконання інструментів відбувається в ізольованому sandbox, коли це ввімкнено.
Це не ідеальна межа безпеки, але вона суттєво обмежує доступ до файлової системи й процесів, коли модель робить щось помилкове.
Що потрапляє в sandbox
- Виконання інструментів (
exec,read,write,edit,apply_patch,processтощо). - Необов’язковий sandbox-браузер (
agents.defaults.sandbox.browser).
Sandboxed browser details
Sandboxed browser details
- За замовчуванням sandbox-браузер автоматично запускається (гарантує доступність CDP), коли він потрібен браузерному інструменту. Налаштовується через
agents.defaults.sandbox.browser.autoStartіagents.defaults.sandbox.browser.autoStartTimeoutMs. - За замовчуванням контейнери sandbox-браузера використовують окрему Docker-мережу (
openclaw-sandbox-browser) замість глобальної мережіbridge. Налаштовується черезagents.defaults.sandbox.browser.network. - Необов’язковий параметр
agents.defaults.sandbox.browser.cdpSourceRangeобмежує CDP-вхід на межі контейнера за допомогою списку дозволених CIDR (наприклад,172.21.0.1/32). - Доступ спостерігача noVNC за замовчуванням захищений паролем; OpenClaw видає короткочасну URL-адресу з токеном, яка віддає локальну сторінку початкового завантаження й відкриває noVNC із паролем у фрагменті URL (не в query/header-логах).
agents.defaults.sandbox.browser.allowHostControlдає sandbox-сесіям змогу явно спрямовуватися на браузер хоста.- Необов’язкові списки дозволеного обмежують
target: "custom":allowedControlUrls,allowedControlHosts,allowedControlPorts.
- Сам процес Gateway.
- Будь-який інструмент, якому явно дозволено запускатися поза sandbox (наприклад,
tools.elevated).- Підвищений exec обходить sandboxing і використовує налаштований шлях виходу (
gatewayза замовчуванням абоnode, коли ціль exec —node). - Якщо sandboxing вимкнено,
tools.elevatedне змінює виконання (воно вже на хості). Див. Підвищений режим.
- Підвищений exec обходить sandboxing і використовує налаштований шлях виходу (
Режими
agents.defaults.sandbox.mode керує тим, коли використовується sandboxing:
- off
- non-main
- all
Без sandboxing.
Область
agents.defaults.sandbox.scope керує тим, скільки контейнерів створюється:
"agent"(типово): один контейнер на агента."session": один контейнер на сесію."shared": один контейнер, спільний для всіх sandbox-сесій.
Бекенд
agents.defaults.sandbox.backend керує тим, яке середовище виконання надає sandbox:
"docker"(типово, коли sandboxing увімкнено): локальне sandbox-середовище виконання на базі Docker."ssh": універсальне віддалене sandbox-середовище виконання на базі SSH."openshell": sandbox-середовище виконання на базі OpenShell.
agents.defaults.sandbox.ssh. OpenShell-специфічна конфігурація міститься в plugins.entries.openshell.config.
Вибір бекенда
| Docker | SSH | OpenShell | |
|---|---|---|---|
| Де запускається | Локальний контейнер | Будь-який SSH-доступний хост | Керований OpenShell sandbox |
| Налаштування | scripts/sandbox-setup.sh | SSH-ключ + цільовий хост | Увімкнений OpenShell Plugin |
| Модель робочої області | Bind-mount або копіювання | Віддалено-канонічна (початкове заповнення один раз) | mirror або remote |
| Керування мережею | docker.network (типово: none) | Залежить від віддаленого хоста | Залежить від OpenShell |
| Браузерний sandbox | Підтримується | Не підтримується | Поки не підтримується |
| Bind mounts | docker.binds | N/A | N/A |
| Найкраще для | Локальної розробки, повної ізоляції | Перенесення навантаження на віддалену машину | Керованих віддалених sandbox із необов’язковою двосторонньою синхронізацією |
Docker-бекенд
Sandboxing вимкнено за замовчуванням. Якщо ви ввімкнете sandboxing і не виберете бекенд, OpenClaw використає Docker-бекенд. Він виконує інструменти й sandbox-браузери локально через сокет демона Docker (/var/run/docker.sock). Ізоляція sandbox-контейнера визначається просторами імен Docker.
Щоб відкрити GPU хоста для Docker-sandbox, задайте agents.defaults.sandbox.docker.gpus або перевизначення для окремого агента agents.list[].sandbox.docker.gpus. Значення передається до прапорця Docker --gpus як окремий аргумент, наприклад "all" або "device=GPU-uuid", і потребує сумісного середовища виконання на хості, такого як NVIDIA Container Toolkit.
SSH-бекенд
Використовуйтеbackend: "ssh", коли хочете, щоб OpenClaw запускав exec, файлові інструменти й читання медіа в sandbox на довільній машині, доступній через SSH.
How it works
How it works
- OpenClaw створює віддалений root для кожної області під
sandbox.ssh.workspaceRoot. - Під час першого використання після створення або повторного створення OpenClaw один раз заповнює цю віддалену робочу область із локальної робочої області.
- Після цього
exec,read,write,edit,apply_patch, читання prompt-медіа й staging вхідних медіа виконуються безпосередньо з віддаленою робочою областю через SSH. - OpenClaw не синхронізує віддалені зміни назад у локальну робочу область автоматично.
Authentication material
Authentication material
identityFile,certificateFile,knownHostsFile: використовують наявні локальні файли й передають їх через конфігурацію OpenSSH.identityData,certificateData,knownHostsData: використовують inline-рядки або SecretRefs. OpenClaw розв’язує їх через звичайний snapshot середовища виконання секретів, записує їх у тимчасові файли з0600і видаляє після завершення SSH-сесії.- Якщо для того самого елемента задано і
*File, і*Data,*Dataмає пріоритет для цієї SSH-сесії.
Remote-canonical consequences
Remote-canonical consequences
Це віддалено-канонічна модель. Віддалена SSH-робоча область стає справжнім станом sandbox після початкового заповнення.
- Локальні для хоста зміни, зроблені поза OpenClaw після кроку заповнення, не видимі віддалено, доки ви не створите sandbox повторно.
openclaw sandbox recreateвидаляє віддалений root для відповідної області й знову заповнює його з локального під час наступного використання.- Браузерний sandbox не підтримується в SSH-бекенді.
- Налаштування
sandbox.docker.*не застосовуються до SSH-бекенда.
OpenShell-бекенд
Використовуйтеbackend: "openshell", коли хочете, щоб OpenClaw запускав інструменти в sandbox у віддаленому середовищі, керованому OpenShell. Повний посібник із налаштування, довідку з конфігурації та порівняння режимів робочої області див. на окремій сторінці OpenShell.
OpenShell повторно використовує той самий базовий SSH-транспорт і віддалений міст файлової системи, що й універсальний SSH-бекенд, і додає специфічний для OpenShell життєвий цикл (sandbox create/get/delete, sandbox ssh-config) плюс необов’язковий режим робочої області mirror.
mirror(типово): локальна робоча область залишається канонічною. OpenClaw синхронізує локальні файли в OpenShell перед exec і синхронізує віддалену робочу область назад після exec.remote: робоча область OpenShell є канонічною після створення sandbox. OpenClaw один раз заповнює віддалену робочу область із локальної, а потім файлові інструменти й exec працюють безпосередньо з віддаленим sandbox без синхронізації змін назад.
Подробиці віддаленого транспорту
Подробиці віддаленого транспорту
- OpenClaw запитує в OpenShell SSH-конфігурацію для конкретної пісочниці через
openshell sandbox ssh-config <name>. - Ядро записує цю SSH-конфігурацію в тимчасовий файл, відкриває SSH-сеанс і повторно використовує той самий віддалений міст файлової системи, що й
backend: "ssh". - У режимі
mirrorвідрізняється лише життєвий цикл: синхронізація локального середовища з віддаленим перед exec, потім зворотна синхронізація після exec.
Поточні обмеження OpenShell
Поточні обмеження OpenShell
- браузер пісочниці поки не підтримується
sandbox.docker.bindsне підтримується в бекенді OpenShell- специфічні для Docker параметри виконання в
sandbox.docker.*досі застосовуються лише до бекенду Docker
Режими робочого простору
OpenShell має дві моделі робочого простору. На практиці це найважливіша частина.- mirror (локальний канонічний)
- remote (OpenShell канонічний)
Використовуйте
plugins.entries.openshell.config.mode: "mirror", коли хочете, щоб локальний робочий простір залишався канонічним.Поведінка:- Перед
execOpenClaw синхронізує локальний робочий простір із пісочницею OpenShell. - Після
execOpenClaw синхронізує віддалений робочий простір назад у локальний робочий простір. - Файлові інструменти й надалі працюють через міст пісочниці, але локальний робочий простір залишається джерелом істини між ходами.
- ви редагуєте файли локально поза OpenClaw і хочете, щоб ці зміни автоматично з’являлися в пісочниці
- ви хочете, щоб пісочниця OpenShell поводилася якомога подібніше до бекенду Docker
- ви хочете, щоб робочий простір хоста відображав записи пісочниці після кожного ходу exec
mirror, якщо сприймаєте пісочницю як тимчасове середовище виконання. Виберіть remote, якщо сприймаєте пісочницю як справжній робочий простір.
Життєвий цикл OpenShell
Пісочниці OpenShell і надалі керуються через звичайний життєвий цикл пісочниці:openclaw sandbox listпоказує середовища виконання OpenShell, а також середовища Dockeropenclaw sandbox recreateвидаляє поточне середовище виконання й дає OpenClaw змогу створити його заново під час наступного використання- логіка prune також враховує бекенд
remote повторне створення особливо важливе:
- повторне створення видаляє канонічний віддалений робочий простір для цієї області
- наступне використання ініціалізує свіжий віддалений робочий простір із локального робочого простору
mirror повторне створення переважно скидає віддалене середовище виконання, бо локальний робочий простір усе одно залишається канонічним.
Доступ до робочого простору
agents.defaults.sandbox.workspaceAccess керує тим, що може бачити пісочниця:
- none (за замовчуванням)
- ro
- rw
Інструменти бачать робочий простір пісочниці в
~/.openclaw/sandboxes.- режим
mirrorі надалі використовує локальний робочий простір як канонічне джерело між ходами exec - режим
remoteвикористовує віддалений робочий простір OpenShell як канонічне джерело після початкової ініціалізації workspaceAccess: "ro"і"none"і надалі обмежують поведінку запису так само
media/inbound/*).
Примітка щодо Skills: інструмент
read прив’язаний до кореня пісочниці. З workspaceAccess: "none" OpenClaw віддзеркалює придатні skills у робочий простір пісочниці (.../skills), щоб їх можна було читати. З "rw" skills робочого простору доступні для читання з /workspace/skills, а придатні керовані, вбудовані або plugin skills матеріалізуються у згенерований шлях лише для читання /workspace/.openclaw/sandbox-skills/skills.Користувацькі bind-монтування
agents.defaults.sandbox.docker.binds монтує додаткові каталоги хоста в контейнер. Формат: host:container:mode (наприклад, "/home/user/source:/source:rw").
Глобальні й агентні binds об’єднуються (не замінюються). За scope: "shared" агентні binds ігноруються.
agents.defaults.sandbox.browser.binds монтує додаткові каталоги хоста лише в контейнер браузера пісочниці.
- Коли задано (зокрема
[]), це замінюєagents.defaults.sandbox.docker.bindsдля контейнера браузера. - Коли пропущено, контейнер браузера повертається до
agents.defaults.sandbox.docker.binds(зворотно сумісно).
Образи й налаштування
Стандартний образ Docker:openclaw-sandbox:bookworm-slim
Вихідний checkout vs встановлення npmДопоміжні скрипти
scripts/sandbox-setup.sh, scripts/sandbox-common-setup.sh і scripts/sandbox-browser-setup.sh доступні лише під час запуску з вихідного checkout. Вони не входять до пакета npm.Якщо ви встановили OpenClaw через npm install -g openclaw, використовуйте наведені нижче inline-команди docker build.Зберіть стандартний образ
З вихідного checkout:З npm-встановлення (вихідний checkout не потрібен):Стандартний образ не містить Node. Якщо skill потребує Node (або інших середовищ виконання), або вбудуйте власний образ, або встановіть через
sandbox.docker.setupCommand (потрібні вихід у мережу + записуваний root + користувач root).OpenClaw не підміняє непомітно відсутній openclaw-sandbox:bookworm-slim простим debian:bookworm-slim. Запуски пісочниці, націлені на стандартний образ, швидко завершуються помилкою з інструкцією зі збирання, доки ви його не зберете, бо вбудований образ містить python3 для допоміжних засобів запису/редагування в пісочниці.Необов'язково: зберіть common-образ
Для функціональнішого образу пісочниці з поширеними інструментами (наприклад, З npm-встановлення спершу зберіть стандартний образ (див. вище), а потім зберіть common-образ поверх нього, використовуючи
curl, jq, Node 24, pnpm, python3 і git):З вихідного checkout:scripts/docker/sandbox/Dockerfile.common з репозиторію.Потім установіть agents.defaults.sandbox.docker.image у openclaw-sandbox-common:bookworm-slim.Необов'язково: зберіть образ браузера пісочниці
З вихідного checkout:З npm-встановлення зберіть за допомогою
scripts/docker/sandbox/Dockerfile.browser з репозиторію.agents.defaults.sandbox.docker.network.
Стандартні налаштування Chromium для браузера пісочниці
Стандартні налаштування Chromium для браузера пісочниці
Вбудований образ браузера пісочниці також застосовує консервативні стартові налаштування Chromium для контейнеризованих навантажень. Поточні стандартні налаштування контейнера включають:
--remote-debugging-address=127.0.0.1--remote-debugging-port=<derived from OPENCLAW_BROWSER_CDP_PORT>--user-data-dir=${HOME}/.chrome--no-first-run--no-default-browser-check--disable-3d-apis--disable-gpu--disable-dev-shm-usage--disable-background-networking--disable-extensions--disable-features=TranslateUI--disable-breakpad--disable-crash-reporter--disable-software-rasterizer--no-zygote--metrics-recording-only--renderer-process-limit=2--no-sandbox, коли ввімкненоnoSandbox.- Три прапорці посилення графіки (
--disable-3d-apis,--disable-software-rasterizer,--disable-gpu) необов’язкові й корисні, коли контейнери не мають підтримки GPU. УстановітьOPENCLAW_BROWSER_DISABLE_GRAPHICS_FLAGS=0, якщо ваше навантаження потребує WebGL або інших 3D/браузерних функцій. --disable-extensionsувімкнено за замовчуванням; його можна вимкнути черезOPENCLAW_BROWSER_DISABLE_EXTENSIONS=0для потоків, що залежать від розширень.--renderer-process-limit=2керується черезOPENCLAW_BROWSER_RENDERER_PROCESS_LIMIT=<N>, де0зберігає стандартне значення Chromium.
browser.extraArgs, щоб додати додаткові стартові прапорці.Стандартні налаштування мережевої безпеки
Стандартні налаштування мережевої безпеки
network: "host"заблоковано.network: "container:<id>"заблоковано за замовчуванням (ризик обходу через приєднання до простору імен).- Аварійний виняток:
agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin: true.
scripts/docker/setup.sh може ініціалізувати конфігурацію пісочниці. Установіть OPENCLAW_SANDBOX=1 (або true/yes/on), щоб увімкнути цей шлях. Розташування сокета можна перевизначити за допомогою OPENCLAW_DOCKER_SOCKET. Повне налаштування й довідник змінних середовища: Docker.
setupCommand (одноразове налаштування контейнера)
setupCommand запускається один раз після створення контейнера пісочниці (не під час кожного запуску). Виконується всередині контейнера через sh -lc.
Шляхи:
- Глобально:
agents.defaults.sandbox.docker.setupCommand - Для окремого агента:
agents.list[].sandbox.docker.setupCommand
Поширені помилки
Поширені помилки
- Стандартне значення
docker.network—"none"(без вихідного доступу), тому встановлення пакетів завершуватиметься помилкою. docker.network: "container:<id>"потребуєdangerouslyAllowContainerNamespaceJoin: trueі призначене лише для аварійного винятку.readOnlyRoot: trueзабороняє записи; установітьreadOnlyRoot: falseабо підготуйте власний образ.- Для встановлення пакетів
userмає бути root (пропустітьuserабо встановітьuser: "0:0"). - Виконання в пісочниці не успадковує
process.envхоста. Використовуйтеagents.defaults.sandbox.docker.env(або власний образ) для API-ключів Skills. - Значення в
agents.defaults.sandbox.docker.envпередаються як явні змінні середовища контейнера Docker. Будь-хто з доступом до демона Docker може переглянути їх командами метаданих Docker, як-отdocker inspect. Використовуйте власний образ, змонтований файл із секретами або інший шлях доставлення секретів, якщо таке розкриття метаданих неприйнятне.
Політика інструментів і аварійні виходи
Політики дозволу/заборони інструментів усе ще застосовуються перед правилами пісочниці. Якщо інструмент заборонено глобально або для окремого агента, пісочниця не повертає його назад.tools.elevated — це явний аварійний вихід, який запускає exec поза пісочницею (gateway за замовчуванням або node, коли ціль виконання — node). Директиви /exec застосовуються лише для авторизованих відправників і зберігаються в межах сеансу; щоб жорстко вимкнути exec, використовуйте заборону в політиці інструментів (див. Пісочниця, політика інструментів і Elevated).
Налагодження:
- Використовуйте
openclaw sandbox explain, щоб перевірити фактичний режим пісочниці, політику інструментів і ключі конфігурації для виправлення. - Див. Пісочниця, політика інструментів і Elevated, щоб зрозуміти модель мислення для питання «чому це заблоковано?».
Перевизначення для кількох агентів
Кожен агент може перевизначати пісочницю та інструменти:agents.list[].sandbox і agents.list[].tools (а також agents.list[].tools.sandbox.tools для політики інструментів пісочниці). Див. Пісочниця й інструменти для кількох агентів, щоб дізнатися про пріоритет.
Мінімальний приклад увімкнення
Пов’язане
- Пісочниця й інструменти для кількох агентів — перевизначення для окремих агентів і пріоритет
- OpenShell — налаштування керованого бекенда пісочниці, режими робочої області та довідник конфігурації
- Конфігурація пісочниці
- Пісочниця, політика інструментів і Elevated — налагодження «чому це заблоковано?»
- Безпека