---
read_when: You want a dedicated explanation of sandboxing or need to tune agents.defaults.sandbox.
status: active
summary: 'Як працює ізоляція OpenClaw: режими, області дії, доступ до робочого простору та зображення'
title: Ізоляція
x-i18n:
    generated_at: "2026-04-14T01:21:00Z"
    model: gpt-5.4
    provider: openai
    source_hash: 2573d0d7462f63a68eb1750e5432211522ff5b42989a17379d3e188468bbce52
    source_path: gateway/sandboxing.md
    workflow: 15
---

# Ізоляція

OpenClaw може запускати **інструменти всередині бекендів ізоляції**, щоб зменшити радіус ураження.
Це **необов’язково** і керується конфігурацією (`agents.defaults.sandbox` або
`agents.list[].sandbox`). Якщо ізоляцію вимкнено, інструменти працюють на хості.
Gateway залишається на хості; виконання інструментів відбувається в ізольованому середовищі ізоляції,
коли цю функцію ввімкнено.

Це не є ідеальною межею безпеки, але суттєво обмежує доступ до файлової системи
та процесів, коли модель робить щось нерозумне.

## Що ізолюється

- Виконання інструментів (`exec`, `read`, `write`, `edit`, `apply_patch`, `process` тощо).
- Необов’язковий браузер в ізоляції (`agents.defaults.sandbox.browser`).
  - За замовчуванням браузер в ізоляції запускається автоматично (щоб CDP був доступний), коли він потрібен інструменту браузера.
    Налаштовується через `agents.defaults.sandbox.browser.autoStart` і `agents.defaults.sandbox.browser.autoStartTimeoutMs`.
  - За замовчуванням контейнери браузера в ізоляції використовують виділену мережу 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-адресу з токеном, яка відкриває локальну bootstrap-сторінку і запускає noVNC з паролем у фрагменті URL (а не в журналах запитів/заголовків).
  - `agents.defaults.sandbox.browser.allowHostControl` дозволяє сеансам в ізоляції явно звертатися до браузера хоста.
  - Необов’язкові списки дозволів контролюють `target: "custom"`: `allowedControlUrls`, `allowedControlHosts`, `allowedControlPorts`.

Не ізолюються:

- Сам процес Gateway.
- Будь-який інструмент, якому явно дозволено працювати поза ізоляцією (наприклад, `tools.elevated`).
  - **Elevated exec обходить ізоляцію і використовує налаштований шлях виходу (`gateway` за замовчуванням або `node`, коли ціллю exec є `node`).**
  - Якщо ізоляцію вимкнено, `tools.elevated` не змінює виконання (воно й так уже на хості). Див. [Режим Elevated](/uk/tools/elevated).

## Режими

`agents.defaults.sandbox.mode` керує **коли** використовується ізоляція:

- `"off"`: без ізоляції.
- `"non-main"`: ізолюються лише **неосновні** сеанси (типовий варіант, якщо ви хочете, щоб звичайні чати працювали на хості).
- `"all"`: кожен сеанс працює в ізоляції.
  Примітка: `"non-main"` визначається за `session.mainKey` (типово `"main"`), а не за id агента.
  Сеанси груп/каналів використовують власні ключі, тож вони вважаються неосновними й будуть ізольовані.

## Область дії

`agents.defaults.sandbox.scope` керує **скільки контейнерів** створюється:

- `"agent"` (типово): один контейнер на агента.
- `"session"`: один контейнер на сеанс.
- `"shared"`: один контейнер, спільний для всіх сеансів в ізоляції.

## Бекенд

`agents.defaults.sandbox.backend` керує **яке середовище виконання** надає ізоляцію:

- `"docker"` (типово): локальне середовище ізоляції на основі Docker.
- `"ssh"`: універсальне віддалене середовище ізоляції на основі SSH.
- `"openshell"`: середовище ізоляції на основі OpenShell.

Конфігурація, специфічна для SSH, розміщується в `agents.defaults.sandbox.ssh`.
Конфігурація, специфічна для OpenShell, розміщується в `plugins.entries.openshell.config`.

### Вибір бекенда

|                     | Docker                           | SSH                            | OpenShell                                                  |
| ------------------- | -------------------------------- | ------------------------------ | ---------------------------------------------------------- |
| **Де виконується**  | Локальний контейнер              | Будь-який хост, доступний по SSH | Кероване OpenShell середовище ізоляції                   |
| **Налаштування**    | `scripts/sandbox-setup.sh`       | SSH-ключ + цільовий хост       | Увімкнений Plugin OpenShell                               |
| **Модель робочого простору** | Bind mount або копіювання        | Віддалений як канонічний (одноразове початкове заповнення) | `mirror` або `remote`                         |
| **Керування мережею** | `docker.network` (типово: none) | Залежить від віддаленого хоста | Залежить від OpenShell                                    |
| **Ізоляція браузера** | Підтримується                   | Не підтримується               | Ще не підтримується                                       |
| **Bind mounts**     | `docker.binds`                   | N/A                            | N/A                                                        |
| **Найкраще підходить для** | Локальної розробки, повної ізоляції | Винесення на віддалену машину | Керованих віддалених середовищ ізоляції з необов’язковою двосторонньою синхронізацією |

### Бекенд Docker

Бекенд Docker є типовим середовищем виконання: він локально запускає інструменти та браузери в ізоляції через сокет демона Docker (`/var/run/docker.sock`). Ізоляція контейнера визначається просторами імен Docker.

**Обмеження Docker-out-of-Docker (DooD)**:
Якщо ви розгортаєте сам Gateway OpenClaw як Docker-контейнер, він оркеструє сусідні контейнери ізоляції через Docker-сокет хоста (DooD). Це створює конкретне обмеження щодо відображення шляхів:

- **Конфігурація має використовувати шляхи хоста**: конфігурація `workspace` у `openclaw.json` ОБОВ’ЯЗКОВО повинна містити **абсолютний шлях хоста** (наприклад, `/home/user/.openclaw/workspaces`), а не внутрішній шлях контейнера Gateway. Коли OpenClaw просить демон Docker створити середовище ізоляції, демон інтерпретує шляхи відносно простору імен ОС хоста, а не простору імен Gateway.
- **Паритет FS Bridge (ідентичне відображення томів)**: нативний процес Gateway OpenClaw також записує heartbeat- та bridge-файли в каталог `workspace`. Оскільки Gateway інтерпретує той самий рядок (шлях хоста) всередині власного контейнеризованого середовища, розгортання Gateway ОБОВ’ЯЗКОВО повинно містити ідентичне відображення томів, яке нативно зв’язує простір імен хоста (`-v /home/user/.openclaw:/home/user/.openclaw`).

Якщо ви відображаєте шляхи внутрішньо без абсолютного паритету з хостом, OpenClaw нативно викидає помилку дозволів `EACCES` при спробі записати свій heartbeat у контейнерному середовищі, оскільки повністю кваліфікований рядок шляху нативно не існує.

### Бекенд SSH

Використовуйте `backend: "ssh"`, якщо ви хочете, щоб OpenClaw ізолював `exec`, файлові інструменти та читання медіа
на довільній машині, доступній по SSH.

```json5
{
  agents: {
    defaults: {
      sandbox: {
        mode: "all",
        backend: "ssh",
        scope: "session",
        workspaceAccess: "rw",
        ssh: {
          target: "user@gateway-host:22",
          workspaceRoot: "/tmp/openclaw-sandboxes",
          strictHostKeyChecking: true,
          updateHostKeys: true,
          identityFile: "~/.ssh/id_ed25519",
          certificateFile: "~/.ssh/id_ed25519-cert.pub",
          knownHostsFile: "~/.ssh/known_hosts",
          // Або використовуйте SecretRefs / вбудований вміст замість локальних файлів:
          // identityData: { source: "env", provider: "default", id: "SSH_IDENTITY" },
          // certificateData: { source: "env", provider: "default", id: "SSH_CERTIFICATE" },
          // knownHostsData: { source: "env", provider: "default", id: "SSH_KNOWN_HOSTS" },
        },
      },
    },
  },
}
```

Як це працює:

- OpenClaw створює віддалений кореневий каталог для кожної області дії в `sandbox.ssh.workspaceRoot`.
- При першому використанні після створення або повторного створення OpenClaw один раз заповнює цей віддалений робочий простір із локального.
- Після цього `exec`, `read`, `write`, `edit`, `apply_patch`, читання медіа в prompt і підготовка вхідних медіа виконуються безпосередньо у віддаленому робочому просторі через SSH.
- OpenClaw не синхронізує віддалені зміни назад у локальний робочий простір автоматично.

Матеріали автентифікації:

- `identityFile`, `certificateFile`, `knownHostsFile`: використовують наявні локальні файли і передають їх через конфігурацію OpenSSH.
- `identityData`, `certificateData`, `knownHostsData`: використовують вбудовані рядки або SecretRefs. OpenClaw розв’язує їх через звичайний runtime snapshot секретів, записує у тимчасові файли з правами `0600` і видаляє, коли SSH-сеанс завершується.
- Якщо для одного й того самого елемента задано і `*File`, і `*Data`, для цього SSH-сеансу пріоритет має `*Data`.

Це модель, де **канонічним є віддалений стан**. Віддалений робочий простір SSH стає реальним станом ізоляції після початкового заповнення.

Важливі наслідки:

- Локальні зміни на хості, зроблені поза OpenClaw після етапу початкового заповнення, не будуть видимі віддалено, доки ви не створите середовище ізоляції заново.
- `openclaw sandbox recreate` видаляє віддалений кореневий каталог для відповідної області дії та знову виконує початкове заповнення з локального джерела під час наступного використання.
- Ізоляція браузера не підтримується в бекенді SSH.
- Налаштування `sandbox.docker.*` не застосовуються до бекенда SSH.

### Бекенд OpenShell

Використовуйте `backend: "openshell"`, якщо ви хочете, щоб OpenClaw ізолював інструменти в
керованому OpenShell віддаленому середовищі. Повний посібник із налаштування, довідник
з конфігурації та порівняння режимів робочого простору дивіться на
окремій [сторінці OpenShell](/uk/gateway/openshell).

OpenShell повторно використовує той самий базовий транспорт SSH і той самий віддалений міст файлової системи, що й
універсальний бекенд SSH, і додає життєвий цикл, специфічний для OpenShell
(`sandbox create/get/delete`, `sandbox ssh-config`), а також необов’язковий режим робочого простору `mirror`.

```json5
{
  agents: {
    defaults: {
      sandbox: {
        mode: "all",
        backend: "openshell",
        scope: "session",
        workspaceAccess: "rw",
      },
    },
  },
  plugins: {
    entries: {
      openshell: {
        enabled: true,
        config: {
          from: "openclaw",
          mode: "remote", // mirror | remote
          remoteWorkspaceDir: "/sandbox",
          remoteAgentWorkspaceDir: "/agent",
        },
      },
    },
  },
}
```

Режими OpenShell:

- `mirror` (типово): локальний робочий простір залишається канонічним. OpenClaw синхронізує локальні файли в OpenShell перед exec і синхронізує віддалений робочий простір назад після exec.
- `remote`: робочий простір OpenShell стає канонічним після створення середовища ізоляції. OpenClaw один раз заповнює віддалений робочий простір із локального, а потім файлові інструменти та exec працюють безпосередньо з віддаленим середовищем ізоляції без синхронізації змін назад.

Деталі віддаленого транспорту:

- OpenClaw запитує в OpenShell конфігурацію SSH, специфічну для середовища ізоляції, через `openshell sandbox ssh-config <name>`.
- Core записує цю конфігурацію SSH у тимчасовий файл, відкриває SSH-сеанс і повторно використовує той самий віддалений міст файлової системи, що й для `backend: "ssh"`.
- Лише в режимі `mirror` життєвий цикл відрізняється: синхронізація з локального на віддалений простір перед exec, а потім синхронізація назад.

Поточні обмеження OpenShell:

- браузер в ізоляції ще не підтримується
- `sandbox.docker.binds` не підтримується в бекенді OpenShell
- специфічні для Docker параметри середовища виконання в `sandbox.docker.*` як і раніше застосовуються лише до бекенда Docker

#### Режими робочого простору

OpenShell має дві моделі робочого простору. Саме ця частина найважливіша на практиці.

##### `mirror`

Використовуйте `plugins.entries.openshell.config.mode: "mirror"`, якщо ви хочете, щоб **локальний робочий простір залишався канонічним**.

Поведінка:

- Перед `exec` OpenClaw синхронізує локальний робочий простір у середовище OpenShell.
- Після `exec` OpenClaw синхронізує віддалений робочий простір назад у локальний.
- Файлові інструменти все одно працюють через міст ізоляції, але локальний робочий простір залишається джерелом істини між ходами.

Використовуйте це, коли:

- ви редагуєте файли локально поза OpenClaw і хочете, щоб ці зміни автоматично з’являлися в ізоляції
- ви хочете, щоб середовище OpenShell поводилося максимально схоже на бекенд Docker
- ви хочете, щоб робочий простір хоста відображав записи із середовища ізоляції після кожного ходу exec

Компроміс:

- додаткові витрати на синхронізацію до і після exec

##### `remote`

Використовуйте `plugins.entries.openshell.config.mode: "remote"`, якщо ви хочете, щоб **робочий простір OpenShell став канонічним**.

Поведінка:

- Коли середовище ізоляції створюється вперше, OpenClaw один раз заповнює віддалений робочий простір із локального.
- Після цього `exec`, `read`, `write`, `edit` і `apply_patch` працюють безпосередньо з віддаленим робочим простором OpenShell.
- OpenClaw **не** синхронізує віддалені зміни назад у локальний робочий простір після exec.
- Читання медіа під час prompt і далі працює, оскільки файлові та медіа-інструменти читають через міст ізоляції, а не покладаються на локальний шлях хоста.
- Транспорт — це SSH у середовище OpenShell, яке повертає `openshell sandbox ssh-config`.

Важливі наслідки:

- Якщо ви редагуєте файли на хості поза OpenClaw після етапу початкового заповнення, віддалене середовище ізоляції **не** побачить ці зміни автоматично.
- Якщо середовище ізоляції створюється заново, віддалений робочий простір знову заповнюється з локального робочого простору.
- За `scope: "agent"` або `scope: "shared"` цей віддалений робочий простір є спільним у межах тієї самої області дії.

Використовуйте це, коли:

- середовище ізоляції має переважно існувати на віддаленому боці OpenShell
- ви хочете менші накладні витрати на синхронізацію на кожному ході
- ви не хочете, щоб локальні зміни на хості непомітно перезаписували віддалений стан середовища ізоляції

Виберіть `mirror`, якщо сприймаєте середовище ізоляції як тимчасове середовище виконання.
Виберіть `remote`, якщо сприймаєте середовище ізоляції як реальний робочий простір.

#### Життєвий цикл OpenShell

Середовища ізоляції OpenShell і далі керуються через звичайний життєвий цикл ізоляції:

- `openclaw sandbox list` показує як середовища виконання OpenShell, так і середовища виконання Docker
- `openclaw sandbox recreate` видаляє поточне середовище виконання і дозволяє OpenClaw створити його заново під час наступного використання
- логіка очищення теж враховує бекенд

Для режиму `remote` повторне створення особливо важливе:

- повторне створення видаляє канонічний віддалений робочий простір для цієї області дії
- наступне використання створює новий віддалений робочий простір із локального робочого простору

Для режиму `mirror` повторне створення переважно скидає віддалене середовище виконання,
оскільки локальний робочий простір однаково залишається канонічним.

## Доступ до робочого простору

`agents.defaults.sandbox.workspaceAccess` керує **що може бачити середовище ізоляції**:

- `"none"` (типово): інструменти бачать робочий простір ізоляції в `~/.openclaw/sandboxes`.
- `"ro"`: монтує робочий простір агента лише для читання в `/agent` (вимикає `write`/`edit`/`apply_patch`).
- `"rw"`: монтує робочий простір агента для читання й запису в `/workspace`.

З бекендом OpenShell:

- режим `mirror` і далі використовує локальний робочий простір як канонічне джерело між ходами exec
- режим `remote` використовує віддалений робочий простір OpenShell як канонічне джерело після початкового заповнення
- `workspaceAccess: "ro"` і `"none"` і далі так само обмежують можливість запису

Вхідні медіафайли копіюються в активний робочий простір ізоляції (`media/inbound/*`).
Примітка щодо Skills: інструмент `read` прив’язаний до кореня ізоляції. За `workspaceAccess: "none"`
OpenClaw віддзеркалює придатні Skills у робочий простір ізоляції (`.../skills`), щоб
їх можна було читати. За `"rw"` Skills робочого простору доступні для читання з
`/workspace/skills`.

## Власні bind mounts

`agents.defaults.sandbox.docker.binds` монтує додаткові каталоги хоста в контейнер.
Формат: `host:container:mode` (наприклад, `"/home/user/source:/source:rw"`).

Глобальні bind mounts і bind mounts на рівні агента **об’єднуються** (а не замінюються). За `scope: "shared"` bind mounts на рівні агента ігноруються.

`agents.defaults.sandbox.browser.binds` монтує додаткові каталоги хоста лише в контейнер **браузера в ізоляції**.

- Якщо параметр задано (включно з `[]`), він замінює `agents.defaults.sandbox.docker.binds` для контейнера браузера.
- Якщо параметр пропущено, контейнер браузера повертається до `agents.defaults.sandbox.docker.binds` (зворотна сумісність).

Приклад (вихідний код тільки для читання + додатковий каталог даних):

```json5
{
  agents: {
    defaults: {
      sandbox: {
        docker: {
          binds: ["/home/user/source:/source:ro", "/var/data/myapp:/data:ro"],
        },
      },
    },
    list: [
      {
        id: "build",
        sandbox: {
          docker: {
            binds: ["/mnt/cache:/cache:rw"],
          },
        },
      },
    ],
  },
}
```

Примітки щодо безпеки:

- Bind mounts обходять файлову систему ізоляції: вони відкривають шляхи хоста з тим режимом, який ви задаєте (`:ro` або `:rw`).
- OpenClaw блокує небезпечні джерела bind mounts (наприклад: `docker.sock`, `/etc`, `/proc`, `/sys`, `/dev` і батьківські монтування, які відкрили б до них доступ).
- OpenClaw також блокує типові корені облікових даних у домашньому каталозі, наприклад `~/.aws`, `~/.cargo`, `~/.config`, `~/.docker`, `~/.gnupg`, `~/.netrc`, `~/.npm` і `~/.ssh`.
- Перевірка bind mounts — це не просто зіставлення рядків. OpenClaw нормалізує шлях джерела, потім знову розв’язує його через найглибшого наявного предка, а вже потім повторно перевіряє заблоковані шляхи й дозволені корені.
- Це означає, що вихід за межі через батьківський симлінк усе одно безпечно блокується, навіть якщо кінцевий елемент іще не існує. Приклад: `/workspace/run-link/new-file` усе одно розв’язується як `/var/run/...`, якщо `run-link` вказує туди.
- Дозволені корені джерел канонікалізуються так само, тож шлях, який лише виглядає таким, що входить до списку дозволених до розв’язання симлінків, усе одно буде відхилено як `outside allowed roots`.
- Чутливі монтування (секрети, SSH-ключі, службові облікові дані) мають бути `:ro`, якщо тільки це не є абсолютно необхідним.
- Поєднуйте з `workspaceAccess: "ro"`, якщо вам потрібен лише доступ на читання до робочого простору; режими bind mounts залишаються незалежними.
- Див. [Ізоляція vs Політика інструментів vs Elevated](/uk/gateway/sandbox-vs-tool-policy-vs-elevated), щоб зрозуміти, як bind mounts взаємодіють із політикою інструментів і elevated exec.

## Зображення + налаштування

Типове Docker image: `openclaw-sandbox:bookworm-slim`

Зберіть його один раз:

```bash
scripts/sandbox-setup.sh
```

Примітка: типове image **не** містить Node. Якщо навичці потрібен Node (або
інші середовища виконання), або зберіть власне image, або встановіть усе через
`sandbox.docker.setupCommand` (потрібен вихід у мережу + доступний для запису корінь +
користувач root).

Якщо вам потрібне функціональніше image ізоляції з поширеними інструментами (наприклад
`curl`, `jq`, `nodejs`, `python3`, `git`), зберіть:

```bash
scripts/sandbox-common-setup.sh
```

Потім задайте `agents.defaults.sandbox.docker.image` значенням
`openclaw-sandbox-common:bookworm-slim`.

Image браузера в ізоляції:

```bash
scripts/sandbox-browser-setup.sh
```

За замовчуванням Docker-контейнери ізоляції працюють **без мережі**.
Перевизначити це можна через `agents.defaults.sandbox.docker.network`.

Комплектне image браузера в ізоляції також застосовує консервативні типові параметри запуску 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` і `--disable-setuid-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.

Якщо вам потрібен інший профіль середовища виконання, використовуйте власне image браузера і надайте
власну точку входу. Для локальних (неконтейнерних) профілів Chromium використовуйте
`browser.extraArgs`, щоб додати додаткові прапорці запуску.

Типові налаштування безпеки:

- `network: "host"` заблоковано.
- `network: "container:<id>"` типово заблоковано (ризик обходу через приєднання до простору імен).
- Аварійний override: `agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin: true`.

Установлення Docker і контейнеризований gateway описані тут:
[Docker](/uk/install/docker)

Для розгортань gateway у Docker `scripts/docker/setup.sh` може ініціалізувати конфігурацію ізоляції.
Задайте `OPENCLAW_SANDBOX=1` (або `true`/`yes`/`on`), щоб увімкнути цей шлях. Ви можете
перевизначити розташування сокета через `OPENCLAW_DOCKER_SOCKET`. Повне налаштування й довідник
зі змінних середовища: [Docker](/uk/install/docker#agent-sandbox).

## 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` або зберіть власне image.
- Для встановлення пакетів `user` має бути root (не задавайте `user` або задайте `user: "0:0"`).
- Sandbox exec **не** успадковує `process.env` хоста. Використовуйте
  `agents.defaults.sandbox.docker.env` (або власне image) для API-ключів навичок.

## Політика інструментів + шляхи обходу

Політики allow/deny для інструментів усе одно застосовуються раніше за правила ізоляції. Якщо інструмент заборонено
глобально або для конкретного агента, ізоляція його не поверне.

`tools.elevated` — це явний шлях обходу, який запускає `exec` поза ізоляцією (`gateway` за замовчуванням або `node`, коли ціллю exec є `node`).
Директиви `/exec` застосовуються лише для авторизованих відправників і зберігаються для кожного сеансу; щоб повністю вимкнути
`exec`, використовуйте заборону в політиці інструментів (див. [Ізоляція vs Політика інструментів vs Elevated](/uk/gateway/sandbox-vs-tool-policy-vs-elevated)).

Налагодження:

- Використовуйте `openclaw sandbox explain`, щоб переглянути фактичний режим ізоляції, політику інструментів і ключі конфігурації для виправлення.
- Див. [Ізоляція vs Політика інструментів vs Elevated](/uk/gateway/sandbox-vs-tool-policy-vs-elevated) для ментальної моделі «чому це заблоковано?».
  Тримайте все максимально закритим.

## Перевизначення для кількох агентів

Кожен агент може перевизначати ізоляцію й інструменти:
`agents.list[].sandbox` і `agents.list[].tools` (а також `agents.list[].tools.sandbox.tools` для політики інструментів ізоляції).
Див. [Ізоляція та інструменти для кількох агентів](/uk/tools/multi-agent-sandbox-tools) щодо пріоритетів.

## Мінімальний приклад увімкнення

```json5
{
  agents: {
    defaults: {
      sandbox: {
        mode: "non-main",
        scope: "session",
        workspaceAccess: "none",
      },
    },
  },
}
```

## Пов’язана документація

- [OpenShell](/uk/gateway/openshell) -- налаштування керованого бекенда ізоляції, режими робочого простору та довідник з конфігурації
- [Конфігурація ізоляції](/uk/gateway/configuration-reference#agentsdefaultssandbox)
- [Ізоляція vs Політика інструментів vs Elevated](/uk/gateway/sandbox-vs-tool-policy-vs-elevated) -- налагодження «чому це заблоковано?»
- [Ізоляція та інструменти для кількох агентів](/uk/tools/multi-agent-sandbox-tools) -- перевизначення для окремих агентів і пріоритети
- [Безпека](/uk/gateway/security)
