Чем автономнее работает агент, тем острее конфликт: подтверждать каждую команду утомительно, а разрешить всё — страшно. Правила разрешений сопоставляют строку команды с шаблоном, поэтому Bash(rm *) не остановит ни /bin/rm, ни find -delete: правило совпадает с текстом команды, а не с тем, что она делает.

Песочница закрывает зазор иначе. Вы описываете, к каким файлам и доменам команды имеют доступ, и границу обеспечивает операционная система — для каждой Bash-команды и всех её дочерних процессов. Обойти её подбором формулировки нельзя.

Вторая тема урока — про качество кода: команда /security-review проверяет изменения текущей ветки на уязвимости.

Что уже умеем / что добавим

Мы знаем правила разрешений и режимы. Теперь добавим уровень ниже — изоляцию средствами ОС: /sandbox, требования по платформам, два слоя изоляции (файловый и сетевой), режимы одобрения и /security-review.

Что вы узнаете в рамках статьи

• Что даёт песочница и чем она надёжнее правил разрешений
• На каких платформах она работает и что доустановить
• Как настроить файловую и сетевую изоляцию
• Чем режим авто-разрешения отличается от обычных разрешений
• Что проверяет /security-review и каковы границы проверки

Ключевые термины

• Песочница Bash — механизм, ограничивающий доступ команд к файловой системе и сети средствами ОС.
• Seatbelt — встроенный механизм изоляции macOS, на котором работает песочница.
• bubblewrap — утилита изоляции для Linux и WSL2, обеспечивающая файловые ограничения.
• Режим авто-разрешения — режим, в котором команды, поддающиеся изоляции, выполняются без запроса.
• dangerouslyDisableSandbox — параметр, которым Claude может повторить команду вне песочницы.
• /security-review — команда проверки изменений текущей ветки на уязвимости.

Включение и платформы

Песочница работает на macOS, Linux и WSL2. Нативная Windows не поддерживается — там Claude Code запускают внутри дистрибутива WSL2.

На macOS ставить ничего не надо: изоляция использует встроенный Seatbelt. На Linux и WSL2 нужны два пакета:

• bubblewrap — непривилегированная утилита изоляции для файловых ограничений;
• socat — релей сетевого трафика через прокси песочницы.

# Ubuntu/Debian
sudo apt-get install bubblewrap socat

# Fedora
sudo dnf install bubblewrap socat

Начинать стоит с команды: её панель сама показывает, чего не хватает:

/sandbox

Панель открывается с тремя вкладками, плюс Dependencies на Linux, если нет опционального seccomp-фильтра:

• Mode — как одобряются изолированные команды;
• Overrides — можно ли упавшим в песочнице командам выполниться без изоляции (allowUnsandboxedCommands);
• Config — итоговые настройки песочницы.

Если видна только вкладка Dependencies — не хватает обязательного пакета. Проверка идёт при старте, поэтому после установки Claude Code нужно перезапустить.

Выбранный режим сохраняется в .claude/settings.local.json. Чтобы включить песочницу во всех проектах, поставьте sandbox.enabled в true в ~/.claude/settings.json.

Поведение по умолчанию: если песочница не может стартовать, Claude Code покажет предупреждение и выполнит команды без изоляции. Чтобы это стало жёсткой ошибкой, поставьте sandbox.failIfUnavailable в true.

Файловая изоляция

По умолчанию команды в песочнице пишут в рабочий каталог, временный каталог сессии и каталоги из --add-dir, /add-dir или permissions.additionalDirectories. Нужна запись за их пределы — лучше расширить границу, чем выводить инструмент из песочницы:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"]
    }
  }
}

Эти пути обеспечиваются на уровне ОС, поэтому их соблюдают все команды в песочнице и их дочерние процессы.

Есть и обратные правила — denyWrite и denyRead, а allowRead открывает конкретные пути внутри запрещённой области. При пересечении правил чтения побеждает более конкретный путь, причём в обе стороны: запретили домашний каталог и разрешили ~/projects — проект читается; разрешили домашний каталог, но запретили ~/.env — запрет держится, и широкий allow не раскроет секрет незаметно.

Пример, закрывающий домашний каталог, кроме проекта:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

Важная деталь: класть такое надо в проектный .claude/settings.json — относительный путь . разрешается в корень проекта только там. В ~/.claude/settings.json тот же . укажет на ~/.claude, и файлы проекта останутся заблокированными.

Сетевая изоляция

Второй слой независим от первого: сетевой доступ контролирует прокси снаружи песочницы.

По умолчанию не разрешён ни один домен. При первом обращении к новому домену Claude Code спрашивает подтверждения — или, в auto-режиме, отправляет запрос классификатору. Ответ «Да» разрешает хост до конца сессии; «Да, и больше не спрашивать» сохраняет allow-правило WebFetch(domain:...) в локальные настройки. Чтобы не отвечать вовсе, домены задаются заранее:

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Настройка strictAllowlist в значении true переводит режим из «спрашивать» в «запрещать»: хосты вне списка отклоняются. Задаётся в пользовательских, управляемых настройках или через --settings; в настройках репозитория не действует.

Слои независимы: sandbox.filesystem.disabled выключает файловую изоляцию, оставляя сетевую.

Два режима одобрения

Режимов два, и оба обеспечивают одинаковые файловые и сетевые ограничения. Разница только в том, нужно ли подтверждать команды.

Авто-разрешение. Команда, которую можно изолировать, выполняется в песочнице и одобряется автоматически. Остальные уходят в обычный поток разрешений. Даже здесь продолжают действовать:

• явные deny-правила — соблюдаются всегда;
• rm и rmdir на критических путях — идут через обычный поток;
• ask-правила с областью по содержимому вроде Bash(git push *).

Обычные разрешения. Все Bash-команды идут через обычный поток, даже изолированные. Больше контроля, больше подтверждений.

Есть и запасной выход. Некоторые команды в песочнице не работают вовсе: Claude Code сообщает о нарушении изоляции, называя заблокированный путь или хост, и Claude может повторить команду с параметром dangerouslyDisableSandbox — вне песочницы и потому через обычный поток разрешений. Отключается выход настройкой "allowUnsandboxedCommands": false — на вкладке Overrides это Strict sandbox mode. Тогда всё должно либо выполняться в песочнице, либо быть перечислено в excludedCommands.

/security-review: проверка изменений

Эта команда запускается вручную:

/security-review

Она делает разовый проход по изменениям текущей ветки, проверяя дифф на уязвимости.

Границы стоит понимать точно: не репозиторий целиком, а только изменения ветки; читается исходный код в вашем чекауте — не работающий сайт и не задеплоенный сервис. Нужно проверить код, который у вас уже есть, — попросите Claude проверить конкретный файл или каталог.

Куда /security-review встаёт в общий ряд:

Плагин security-guidance из официального marketplace дополняет команду: он работает автоматически и проверяет изменения на трёх уровнях — сопоставление с образцами после каждой правки, фоновый обзор диффа в конце хода, глубокий разбор при коммите или пуше.

/plugin install security-guidance@claude-plugins-official

Оговорка: ни один из слоёв не блокирует запись и коммит. Находки приходят к Claude как инструкции, и модель обзора может что-то пропустить. Это защита в глубину, а не полное решение.

Частые ошибки

• Считать, что песочница есть везде. На нативной Windows она не поддерживается — нужен WSL2. На Linux и WSL2 требуются bubblewrap и socat, без них панель покажет только Dependencies.
• Не заметить тихий откат. Если песочница не стартовала, Claude Code предупреждает и выполняет команды без изоляции. Для жёсткого отказа нужен sandbox.failIfUnavailable.
• Класть правило с путём . в пользовательские настройки. Относительный путь разрешается в корень проекта только в проектных настройках; в ~/.claude/settings.json он укажет на ~/.claude.
• Ждать от /security-review проверки всего репозитория. Она покрывает только изменения текущей ветки. Для остального кода просите проверить конкретный файл или каталог.

Наиболее частые вопросы

• Чем песочница надёжнее правил разрешений? — Правила сопоставляют строку команды с шаблоном, поэтому Bash(rm *) не остановит /bin/rm. Песочница обеспечивается ОС для команды и дочерних процессов.
• Куда пишут изолированные команды по умолчанию? — В рабочий каталог, временный каталог сессии и каталоги из -add-dir или permissions.additionalDirectories.
• Сколько доменов разрешено изначально? — Ни одного. При первом обращении Claude Code спросит подтверждения; заранее домены задаются через network.allowedDomains.
• Работают ли deny-правила в режиме авто-разрешения? — Да, явные deny-правила соблюдаются всегда, как и ask-правила с областью по содержимому.
• Можно ли запретить выход из песочницы? — Да, настройкой "allowUnsandboxedCommands": false. На вкладке Overrides это Strict sandbox mode.

Итоги

Отличная работа: вы добрались до уровня, где границы обеспечивает не договорённость, а операционная система. Вы умеете включать песочницу и знаете её требования по платформам, настраиваете файловые правила с учётом того, что более конкретный путь побеждает, задаёте разрешённые домены, различаете два режима одобрения и знаете границы применимости /security-review.

Запомните неочевидное: по умолчанию неудачный старт песочницы приводит не к отказу, а к выполнению без изоляции. Полагаетесь на неё как на гарантию — включайте failIfUnavailable.

Остались два урока про диагностику: что делать, когда настроено вроде бы всё, а работает не так. На следующем разберём /doctor, /permissions и другие команды, показывающие, что на самом деле загрузилось в сессию.