Изоляция Docker — это основа безопасного режима пропуска разрешений. Без контейнеризации каждый вызов инструмента от ИИ может повлиять на вашу систему, а проверка каждого действия через запросы разрешений сильно тормозит работу. С изоляцией Docker модель свободно работает внутри одноразового контейнера, а вы проверяете конечный результат, а не каждое действие.
Система разрешений
По умолчанию Pastukhov Agent работает в режиме YOLO — все запросы разрешений подтверждаются автоматически. Сервис разрешений записывает утверждённые команды в базу для аудита:
- Паттерны команд — утверждённые команды обобщаются в шаблоны с подстановками (
npm install reactстановитсяnpm install *,git add .становитсяgit add *) и сохраняются в базу. Более 40 встроенных паттернов покрывают менеджеры пакетов (npm, yarn, pip), сборщики (cargo, mvn, gradle), git-операции, команды docker и системные утилиты — в режиме YOLO всё это утверждается автоматически; - Отслеживание на уровне инструментов — для инструментов, не относящихся к Bash (Edit, Read, Write), разрешения хранятся как логические флаги на каждый инструмент;
- Аудитный след — каждая утверждённая команда сохраняется со своим паттерном, оставляя запись о том, что ИИ делал в сессии.
Даже в режиме YOLO хуки по-прежнему могут перехватывать и блокировать отдельные действия — они работают на другом уровне системы проверки.
Модель изоляции Docker
Контейнеры Docker изолируют файловую систему и процессы. Модель внутри контейнера Pastukhov Agent видит только файлы своего контейнера — она не может изменить вашу систему, заглянуть в другие проекты или выполнить команды вне изоляции.
Как это работает
- Монтирование проекта — папка проекта подключается в контейнер по настроенному пути. ИИ видит и меняет только смонтированные файлы;
- Изоляция процессов — команды оболочки, сборки и развёртывания выполняются внутри контейнера. Сбой процесса или вышедшая из-под контроля команда не заденут хост;
- Одноразовые окружения — если что-то пошло не так, контейнер пересоздаётся. Все изменения с последнего коммита остаются внутри него;
- Изоляция учётных данных — ИИ может доустанавливать инструменты, но контейнер стартует без доступа к вашим рабочим системам. Нет строк подключения, ключей API или токенов — нет и пути к рабочим данным.
Инструкции по настройке Docker — на страницах Настройка Docker, Windows Docker Desktop или Mac Docker Desktop.
Важно: никогда не давайте модели ИИ доступ к рабочим (production) системам. Даже когда нужна автоматизация, пусть модель разрабатывает и отлаживает скрипты на тестовых данных, а к рабочей среде применяйте их сами — никогда не позволяйте модели вызывать инструменты, которые напрямую задевают производство. Модели примерно раз на 100 чатов могут неожиданно отклониться от инструкций, часто без ясной причины: неправильно понять задачу, решить сделать то, о чём вы не просили, или просто «забыть» жёсткие правила, когда контекст разрастается. Прежний успешный опыт не гарантирует послушания в будущем — относитесь к каждой сессии как к способной сбиться с пути.
Режим пропуска разрешений
Режим пропуска разрешений обходит все запросы на подтверждение. В обычной консольной версии Claude Code каждый вызов инструмента требует явного одобрения пользователя. Здесь одобрение происходит автоматически — модель свободно работает, не дожидаясь подтверждения каждого действия.
Без изоляции Docker пропуск разрешений рискован: ИИ может удалять файлы, ставить пакеты или запускать произвольные команды на вашем хосте. С Docker худший случай — пересоздать контейнер. Это меняет сам подход к проверке:
- Без изоляции — проверяйте каждое действие и утверждайте каждый вызов инструмента. Медленно, но безопасно для системы;
- С изоляцией — проверяйте результат, а не действия. Дайте модели работать свободно, затем посмотрите git diff и вывод сборки. Быстро и с теми же гарантиями безопасности.
Полностью автоматизированный конвейер проверки
Изоляция Docker, пропуск разрешений, автоматические сборки и Автоисправление складываются в полностью автоматизированный конвейер проверки. Модель свободно работает в контейнере, сборки проверяют каждое изменение, Автоисправление возвращает ошибки модели, а развёртывания перезапускаются сами, когда всё проходит:
- Вы отправляете модели описание задачи;
- Модель читает файлы, пишет код и запускает команды свободно внутри контейнера Docker;
- Изменения файлов запускают автоматические сборки (компилятор, линтер, проверка типов, тесты);
- Парсер сборки извлекает из вывода ошибки и предупреждения;
- Автоисправление подставляет ошибки как сообщения чата — модель видит, что именно сломалось;
- Модель исправляет ошибки, и это снова запускает сборки (цикл повторяется);
- Когда все сборки прошли, развёртывание перезапускается само;
- Вывод развёртывания разбирается на ошибки времени выполнения;
- Вы смотрите конечный результат: git diff по коду, панель сборки по проверкам, диалог развёртывания по работоспособности.
Ключевая мысль: вы переходите от проверки действий (одобрение каждого вызова инструмента) к проверке результата (просмотр итога). Это быстрее, менее утомительно и одинаково безопасно, если изоляция Docker на месте.
Эффективные приёмы проверки
- Всегда используйте Docker для ИИ-разработки — сочетание Docker + пропуск разрешений + Автоисправление — рекомендуемая рабочая настройка. Ручное одобрение не масштабируется;
- Проверяйте изменения git, а не отдельные действия — когда модель закончила, просмотрите панель git на неожиданные изменения. Это ловит то, что не видят сборки;
- Используйте хуки для запрета конкретных действий — даже при пропуске разрешений хуки могут запрещать отдельные команды, например ручные сборки или опасные операции;
- Никогда не раскрывайте рабочие учётные данные — не передавайте в контейнер строки подключения, ключи API и токены доступа. ИИ может установить любой нужный инструмент, поэтому изоляция учётных данных — ваша единственная защита от доступа к внешним системам.
Инструкции по настройке Docker — на странице Настройка Docker, автоматический цикл обратной связи по ошибкам — в Автоисправлении, запрет конкретных действий — в Хуки: управление поведением модели.