Открытый гайд · ИИ-офис

Claude Code в Docker:безопасное окружение в контейнере

Контейнер — это граница, за которую агент не выйдет. Разберём, зачем сажать Claude Code в Docker, какие бывают уровни изоляции, как поднять готовый dev-контейнер и где честная граница этого подхода.

@kir.player
~11 минут
июнь 2026

Чем больше свободы ты даёшь Claude Code, тем выше цена ошибки. Агент, который сам запускает команды и правит файлы без твоего подтверждения, экономит уйму времени — но на голой системе один кривой шаг может задеть то, что трогать было нельзя. Docker решает это в лоб: Claude работает внутри контейнера, изолированно от твоей машины. Если что-то пойдёт не так, ломается контейнер, а не рабочий ноутбук.

Что узнаешь из гайда

  • Зачем вообще изолировать Claude Code и от чего это защищает
  • Уровни изоляции: от sandbox до полноценного контейнера
  • Как поднять готовый dev-контейнер с фаерволом
  • Почему контейнер делает безопасным --dangerously-skip-permissions
  • Когда контейнер — лишняя возня

Часть 1 · Смысл

Зачем сажать агента в контейнер

Главное

Изоляция ограничивает урон: контейнер задаёт, что Claude может читать, писать и до какой сети дотягиваться. Это нужно, когда ты убираешь подтверждения, запускаешь агента надолго без присмотра или направляешь его на чужой код.

Расшифруем по словам. Контейнер — это лёгкая изолированная коробка, в которой крутится программа со своей файловой системой и своими правилами доступа к сети, отдельно от твоей основной системы (хоста). Хост — это твой реальный компьютер. Идея простая: внутри контейнера Claude видит только проект и то, что ты ему явно дал, а до остального хоста не дотянется.

Когда это реально окупается. Во-первых, если хочешь убрать подтверждения и работать быстрее — изоляция страхует от того, что агент в авторежиме сделает лишнее. Во-вторых, для долгих автономных прогонов, когда ты не сидишь и не одобряешь каждый шаг. В-третьих, при работе с незнакомым или непроверенным репозиторием, где в коде или в инструкциях может прятаться что-то враждебное.

Изоляция не убирает риск, она ограничивает его последствия. Контейнер — это страховка, а не отключение мозга.


Часть 2 · Варианты

Уровни изоляции: от sandbox до контейнера

Главное

У Claude Code несколько уровней изоляции. Sandbox — самый лёгкий, без Docker, но ограничивает только bash. Контейнер тяжелее, требует Docker, зато прячет внутрь весь процесс целиком.

Прежде чем бежать за Docker, полезно понять всю лестницу. Встроенный sandbox для bash включается командой /sandbox и использует средства самой ОС, чтобы ограничить файлы и сеть для каждой bash-команды. Но файловые инструменты, MCP-серверы и хуки при этом по-прежнему работают прямо на хосте — sandbox их не закрывает.

Сравнение по уровню изоляции

ПодходЧто изолируетНужен Docker
Sandbox для bashТолько bash-командыНет
Sandbox-runtimeВесь процесс Claude CodeНет
Dev-контейнерВсё окружение разработкиДа
Виртуальная машинаВсю операционную системуНет

Между sandbox и контейнером есть промежуточный вариант без Docker — sandbox-runtime. Это пакет, который оборачивает весь процесс Claude Code в ту же изоляцию средствами ОС, что и встроенный sandbox, но уже целиком — со всеми инструментами, хуками и MCP. Запуск одной командой через npx:

терминал · sandbox-runtime без Docker
# Оборачиваем весь процесс Claude Code в изоляцию средствами ОС.
# По умолчанию запись и сеть запрещены — настройки лежат в
# ~/.srt-settings.json (разреши там проект и api.anthropic.com).
npx @anthropic-ai/sandbox-runtime claude

Если Docker ставить не хочешь, а изолировать нужно всё — это твой вариант. Но самый предсказуемый и переносимый способ изоляции — всё же контейнер: окружение фиксировано, его легко раздать команде.


Часть 3 · Готовое решение

Готовый dev-контейнер с фаерволом

Главное

Не пиши контейнер с нуля. Anthropic даёт готовый пример dev-контейнера с фаерволом default-deny. Копируешь папку .devcontainer/ в репозиторий, правишь allowlist под себя — и можно работать без подтверждений.

Dev-контейнер — это Docker-контейнер, которым управляет VS Code или совместимый редактор, с проектом, смонтированным внутрь. Конфигурация описана в папке .devcontainer/ прямо в репозитории. Готовый пример из репозитория Claude Code идёт с iptables-фаерволом по принципу default-deny — то есть сеть запрещена по умолчанию, и открыты только адреса из белого списка.

Что значит «default-deny» на практике: даже если внутри контейнера что-то попытается отправить данные наружу на чужой адрес, фаервол это заблокирует — в allowlist его нет. Именно поэтому такая конфигурация позволяет спокойно гонять автономную работу.

структура · .devcontainer в репозитории
# Копируешь готовый пример из репозитория Claude Code к себе:
.devcontainer/
  devcontainer.json   # образ, версия Claude Code, монтирование проекта
  Dockerfile          # базовый образ + установка инструментов
  init-firewall.sh    # iptables default-deny + allowlist доменов

# Дальше: правишь allowlist под свои домены (npm, GitHub, твой провайдер),
# фиксируешь версию Claude Code — и открываешь проект в контейнере.

Важно

Dev-контейнер — это соглашение, а не жёсткая принудиловка: сам Claude Code не требует контейнера и спокойно запустится и без него. Если в команде договорились работать только через контейнер — это нужно дополнительно следить организационно. Открыть проект в контейнере проще всего из VS Code с расширением Dev Containers.


Часть 4 · Под себя

Свой Docker-образ под проект

Главное

Claude Code запускается в любом Docker-образе со своими политиками сети и смонтированными томами. Это путь для тех, у кого уже есть своя контейнерная инфраструктура или CI-раннеры.

Если готовый dev-контейнер не подходит, собираешь свой. Логика та же: кладёшь Claude Code в образ, монтируешь проект внутрь, настраиваешь, что именно доступно по сети. Главные вопросы, на которые надо ответить честно перед запуском без присмотра:

  1. Что смонтировано на запись. Контейнер всё ещё может менять код, который ты дал ему писать. Монтируй внутрь только нужное.
  2. Какие токены достижимы внутри. Если в контейнер попали ключи и токены — агент сможет их использовать. Не тащи лишние секреты.
  3. Что разрешает сеть. Любой выход в сеть — это потенциальная утечка того, что агент прочитал. Держи egress узким.

Можно складывать уровни: запустить встроенный bash-sandbox внутри контейнера — тогда поверх внешней границы контейнера получаешь ещё и пожёстче ограничения на каждую команду. А для самого серьёзного случая — непроверенный код, требование разделения на уровне ядра — берут уже не контейнер, а отдельную виртуальную машину.

Коротко

  • Без Docker: /sandbox для bash или npx @anthropic-ai/sandbox-runtime claude для всего процесса.
  • С Docker: готовый dev-контейнер с default-deny-фаерволом или свой образ.
  • Перед автономным прогоном проверь: что на запись, какие токены, какая сеть.

Часть 5 · Дисциплина

Правила работы в контейнере

Контейнер развязывает руки, но не отменяет здравый смысл. Вот связка, которая реально окупается. Изоляция и права работают вместе: права решают, запускать ли действие вообще, а контейнер ограничивает, до чего это действие дотянется.

Рабочая связка

Внутри dev-контейнера с фаерволом запускаешь claude --dangerously-skip-permissions для автономной работы. Контейнер — единственная граница, и этого достаточно: агент работает быстро и без вопросов, но заперт внутри. На хосте тот же флаг был бы опасен.

Хорошо ложится сюда и автономный фоновый формат. Долгие прогоны, headless-запуски, циклы — всё это безопаснее гонять в изолированном окружении. Если интересен автономный режим, посмотри гайд про loop-кодинг и про headless-запуск без чата — оба отлично сочетаются с контейнером.

Когда контейнер не нужен

Для обычной работы на своей машине с подтверждениями контейнер — лишняя возня. Хочешь меньше вопросов без Docker — включи встроенный /sandbox. Контейнер берут целенаправленно: под автономную работу, чужой код или общий стандарт окружения в команде, а не «чтобы было». И помни: изоляция не меняет то, что отправляется в модель — твои промты и прочитанные файлы всё равно уходят в API.

Коротко

  • Контейнер — граница урона, права — фильтр действий. Работают вместе.
  • --dangerously-skip-permissions только внутри изоляции, никогда на хосте.
  • Автономные прогоны (loop, headless) безопаснее в контейнере; для обычной работы хватит /sandbox.

Вопросы

Частые вопросы

Зачем запускать Claude Code в Docker?

Docker даёт изоляцию: Claude работает внутри контейнера и не может задеть файлы и сеть основной системы за пределами проекта. Это нужно, когда хочешь дать агенту больше свободы — например, запустить его без подтверждений на каждый шаг — и не бояться, что он что-то сломает на хосте. Контейнер ограничивает урон, если что-то пойдёт не так.

Что такое dev-контейнер для Claude Code?

Dev-контейнер — это Docker-контейнер с настроенным окружением разработки, которым управляет VS Code или совместимый редактор. Конфигурация лежит в папке .devcontainer/ внутри репозитория, а проект монтируется внутрь. Anthropic публикует готовый пример dev-контейнера с фаерволом по принципу default-deny — его копируют к себе и правят под проект.

Безопасно ли давать Claude Code dangerously-skip-permissions в контейнере?

Внутри изолированного контейнера с фаерволом флаг --dangerously-skip-permissions безопаснее, чем на голом хосте. Контейнер становится границей: даже без подтверждений на каждое действие агент заперт внутри и не дотянется до остальной системы. На обычной машине этот флаг давать нельзя — он снимает все проверки разом. Подробно про права — в гайде про безопасность Claude Code.

Чем dev-контейнер отличается от sandbox-режима Claude Code?

Встроенный sandbox ограничивает только bash-команды, а файловые операции, MCP-серверы и хуки всё равно идут на хосте. Контейнер же помещает внутрь границы весь процесс Claude Code целиком — изолировано всё, не только bash. Контейнер требует Docker и больше настройки, зато даёт полную изоляцию окружения.

Читать дальше

Соседние гайды

Telegram про вайбкодинг и ИИ

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

Зайти в Telegram