Свой воркфлоу-sandbox вокруг Claude Code

Почему стандартного режима Claude Code недостаточно

Представьте: вы запускаете Claude Code, даёте задачу — «реализуй фичу X», и он начинает работать. Через минуту просит разрешение запустить bash. Ещё через минуту — записать файл. Потом — установить зависимости. Потом снова. И снова. Тридцать подтверждений спустя вы жмёте «approve» уже не читая.

Это называется «approval fatigue» — усталость от подтверждений. Чем чаще вы нажимаете «одобрить», тем меньше внимания уделяете каждому запросу, и это превращается в угрозу безопасности, замаскированную под функцию защиты.

Поэтому сообщество разработчиков пошло другим путём: строить собственный workflow-sandbox вокруг Claude Code. Не терпеть неудобства «из коробки», а переосмыслить архитектуру взаимодействия с агентом.

В этой статье — практическое руководство: зачем нужен кастомный sandbox, как он устроен, какие инструменты реально работают, и какие грабли подстерегают на пути.

Что такое workflow-sandbox и зачем он нужен

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

Но встроенный sandbox — только часть картины. Настоящий workflow-sandbox — это целая система:

Изоляция файловой системы и сети (OS-level)
Детерминированные хуки вместо вероятностных промптов
MCP-серверы для связи с внешними инструментами
Slash-команды и субагенты для повторяющихся задач
Чёткая последовательность шагов (plan → implement → verify)

ℹ Ключевая идея

Workflow-sandbox — это не просто безопасность. Это архитектура, которая делает Claude Code предсказуемым, быстрым и встроенным в ваш реальный production-процесс.

Проблема: Claude Code ведёт себя непредсказуемо

На протяжении нескольких месяцев разработчики пытаются заставить Claude Code следовать строго определённому воркфлоу: генерировать код по требованиям, обновлять переменные окружения и определения зависимостей, загружать код в облачный sandbox, устанавливать зависимости, запускать код, скачивать логи и проверять корректность. И всё это должно происходить в строгой последовательности с использованием API облачного окружения.

Попытки заставить агента следовать точной последовательности работали «в общем-то», но были крайне нестабильными — Claude периодически путался и выполнял неверный шаг или вызывал не тот инструмент. Кроме того, это было мучительно медленно, а сложные промпты и описания MCP-инструментов приводили к раздуванию контекста.

Описания MCP-инструментов занимали 34% контекста ещё до начала какой-либо работы!

Вывод прост: нельзя полностью полагаться на «вероятностную» природу LLM там, где нужна детерминированность. Нужна гибридная архитектура.

Архитектура кастомного workflow-sandbox


graph TD
    A[Задача / промпт] --> B[Plan Mode]
    B --> C{Одобрение плана}
    C -->|Да| D[Agentic Execution]
    C -->|Нет| B
    D --> E[Детерминированные хуки]
    E --> F[Sandbox: файловая система + сеть]
    F --> G[MCP-серверы]
    G --> H[Внешние инструменты: Slack / Git / БД]
    D --> I[Субагенты]
    I --> J[Верификация результата]
    J -->|Ошибка| D
    J -->|OK| K[Deploy / PR]

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

Слой 1: Sandbox — изоляция на уровне ОС

Инструмент sandboxed bash использует примитивы безопасности уровня операционной системы для обеспечения изоляции файловой системы и сети.

Инструмент sandboxed bash ограничивает доступ к файлам конкретными директориями: запись по умолчанию разрешена только в текущую рабочую директорию и её поддиректории, чтение охватывает всю систему (кроме явно запрещённых директорий), а модификации за пределами рабочей директории блокируются без явного разрешения.

Без границ один скомпрометированный пакет может прочитать ваши SSH-ключи, утащить переменные окружения или подменить конфиг shell. Функция sandboxing в Claude Code решает эту проблему через принуждение на уровне ОС, ограничивая доступ к файловой системе и сети на уровне ядра, а не через доверие или prompt engineering.

Для Docker-based изоляции существует open-source инструмент:

Основная цель Claude Code Sandbox — включить полностью асинхронные агентные воркфлоу, позволяя Claude Code выполняться без запросов разрешений. Запуская Claude в изолированном Docker-контейнере с флагом --dangerously-skip-permissions, агент может выполнять любую команду мгновенно. Это создаёт по-настоящему автономного ассистента разработки, похожего на OpenAI Codex или Google Jules, но работающего локально на вашем компьютере с полным контролем.

# Быстрый старт с Docker-sandbox
npx claude-sandbox start --name my-project

# Подключиться к контейнеру
npx claude-sandbox attach

# Посмотреть логи
npx claude-sandbox logs -f

Слой 2: Детерминированные хуки вместо промптов

Хуки выполняют детерминированные shell-команды в определённых точках воркфлоу Claude Code. В отличие от промптов с просьбой выполнить действие, хуки гарантируют выполнение независимо от поведения модели. Они необходимы для соблюдения командных стандартов и автоматизации повторяющихся задач.

Разница принципиальная: сказать Claude «всегда запускай Prettier после редактирования файлов» работает иногда. Но Claude может забыть, поставить скорость в приоритет, или решить, что изменение «слишком маленькое». Хуки гарантируют выполнение — каждое редактирование или запись триггерит форматтер, каждый раз, без исключений.

Создатель Claude Code Борис Черни использует PostToolUse хук для форматирования кода. Claude обычно генерирует хорошо отформатированный код, а хук обрабатывает последние 10%, чтобы избежать ошибок форматирования в CI.

Слой 3: MCP — связь с реальным миром

MCP расширяет Claude Code доступом к внешним инструментам, базам данных, API и сервисам через стандартизированный протокол. Экосистема выросла со 100 000 загрузок в ноябре 2024 года до более чем 8 миллионов к апрелю 2025-го — рост в 80 раз за пять месяцев. Существует более 300 интеграций: GitHub, Slack, PostgreSQL и кастомные корпоративные системы.

Claude Code использует все инструменты автоматически: ищет и публикует в Slack через MCP-сервер, выполняет запросы BigQuery для аналитики, забирает логи из Sentry и многое другое. Конфигурация Slack MCP зафиксирована в .mcp.json и расшарена с командой.

💡 Практический совет

Подключайте MCP-серверы постепенно. Каждое описание инструмента занимает место в контексте. Начните с 2-3 самых нужных интеграций и добавляйте по мере необходимости.

Слой 4: Slash-команды и субагенты

Создатель Claude Code использует slash-команды для каждого цикличного воркфлоу, который он выполняет много раз в день. Это избавляет от повторяющихся промптов и позволяет самому Claude использовать эти воркфлоу. Команды хранятся в git и живут в директории .claude/commands/.

Сторонние инструменты типа claude-code-workflows реализуют end-to-end воркфлоу, в которых специализированные агенты берут на себя требования, дизайн, реализацию и проверку качества — в результате получается код, который реально проходит тесты и соответствует проектной документации.

Гибридная модель: агент + детерминированный код

Главный инсайт, к которому приходят все разработчики, строящие сложные воркфлоу:

Нельзя доверить LLM весь pipeline целиком. Лучшие воркфлоу — это микс агентных шагов и детерминированного кода.

Весь воркфлоу в итоге представляет собой смесь агентных шагов («напиши этот код и измени файлы согласно требованиям») и детерминированных шагов (вызов API «A» после завершения шага генерации кода).

Для управления Claude Code из другой программы используется Claude Code SDK. SDK позволяет попросить Claude Code создать Python-приложение, а когда оно готово — передать управление обратно воркфлоу-движку для перехода к следующему шагу. Следующим шагом обычно является загрузка кода и зависимостей в облачный sandbox, запуск приложения и скачивание логов. Всё это выполнялось через «детерминированный код», который вызывал правильные API в заранее определённой последовательности.

Тип шага	Исполнитель	Примеры
Генерация кода	Claude Code (агент)	Написать функцию, рефакторинг, тесты
Форматирование	Хук (детерминированный)	Prettier, Black, ESLint
Деплой в sandbox	Детерминированный скрипт	`docker build`, `npm install`
Проверка логов	Claude Code (агент)	Анализ ошибок, итерация
Push + PR	Slash-команда	`/commit-push-pr`
Уведомления	MCP-сервер	Slack, Jira, Linear

Auto Mode vs –dangerously-skip-permissions

Эта дилемма возникает у каждого, кто хочет убрать прерывания в workflow.

Флаг --dangerously-skip-permissions делает именно то, что заявлено: убирает весь слой подтверждений. Каждая shell-команда, запись файла, сетевой вызов и git-операция выполняются без запроса. Это привлекает: ноль прерываний. Это же является ценой.

Флаг — это инструмент для sandbox. Запустите его внутри одноразового контейнера, чистой VM или scratch worktree — всё в порядке. Запустите против вашего реального репозитория на вашем реальном ноутбуке — история безопасности превращается в «надеемся, ничего странного не случится».

Auto Mode закрывает этот пробел. Вместо того чтобы убирать слой разрешений, он направляет каждый вызов инструмента через шлюз разрешений, который решает, что безопасно запускать, ограничиваясь по умолчанию рабочей директорией и текущими remote-репозиториями.

⚠ Важно

Никогда не используйте --dangerously-skip-permissions напрямую на вашем основном компьютере или в production-репозитории. Только внутри изолированного контейнера или виртуальной машины.

Режим	Изоляция	Скорость	Безопасность	Когда использовать
Стандартный (с подтверждениями)	Нет	Низкая	Высокая	Знакомство с проектом
Auto Mode	Частичная (AI-gate)	Высокая	Средняя	Ежедневная разработка
Sandbox (OS-level)	Полная	Высокая	Высокая	Постоянная работа
`--dangerously-skip-permissions`	Нет (если нет Docker)	Максимальная	Низкая	Только в изолированном контейнере

Plan Mode: фундамент надёжного воркфлоу

Большинство сессий начинаются в Plan Mode (Shift+Tab дважды). Если цель — написать Pull Request, используется Plan Mode: идёт диалог с Claude до тех пор, пока план не станет удовлетворительным. После этого переключаются в режим автоматического принятия правок, и Claude, как правило, делает всё за один проход. Хороший план — это действительно важно!

Финальный совет от создателя Claude Code: вероятно, самое важное для получения отличных результатов — дать Claude способ верифицировать свою работу. Если у Claude есть такой цикл обратной связи, качество финального результата возрастает в 2-3 раза.

# Пример структуры CLAUDE.md для проекта

## Контекст проекта
Проект: [название]
Техстек: Node.js, PostgreSQL, React

## Правила воркфлоу
1. Всегда начинай с Plan Mode для задач > 30 минут
2. После генерации кода запускай тесты автоматически
3. Используй /commit-push-pr только после зелёных тестов

## Запрещено
- Не модифицируй .env напрямую
- Не устанавливай пакеты без подтверждения в Plan Mode
- Не делай push в main напрямую

📝 Реальный кейс

Один разработчик построил pipeline для автоматической генерации лекционных материалов PhD-курса по каузальным данным: 6 полных лекций (140+ слайдов каждая), с версиями Beamer и Quarto, интерактивными Plotly-графиками, TikZ-диаграммами и R-скриптами — всё под управлением оркестратора и проверялось 14 специализированными агентами по 5 измерениям качества.

Мультиагентный подход и управление контекстом

Опытные пользователи придерживаются правила: никогда не превышать 60% контекста. Работа разбивается на 4 фазы: Research → Plan → Implement → Validate. Контекст очищается между каждой фазой.

Не все агенты должны использовать одну и ту же модель. Каждый файл агента имеет поле model: в YAML frontmatter. По умолчанию все агенты используют model: inherit. Принцип оптимизации: Opus — для задач, требующих удержания двух больших документов одновременно. Sonnet — для задач с чёткими ограниченными рамками.

Полезные плагины для мультиагентного воркфлоу: claude-code-discover превращает идеи фич в PRD с доказательной базой; metronome обнаруживает поведение «срезания углов» и подталкивает Claude двигаться пошагово; linear-prism превращает требования в структурированные задачи Linear.

Что реально работает: опыт сообщества

По наблюдениям разработчиков на Hacker News и Reddit, Sonnet лучше для CLI-операций, git-операций, написания кода в режиме пары, архитектурного обсуждения. Многие используют Claude Code именно для git-операций и bash-скриптинга, где IDE-инструменты кажутся избыточными.

Разработчики документируют создание функциональных SaaS-приложений за несколько часов. Суbreddit r/vibecoding с 89k участников регулярно публикует логи сборки с Claude Code. Устойчивый паттерн: Claude Code для терминала и архитектурной работы, Cursor или Windsurf — для доработки в IDE.

Даже не-разработчикам не нужно погружаться в детали: при настройке воркфлоу Claude Code всё определяется в Markdown-файлах на простом английском языке, и предоставление Claude возможности самостоятельно находить нужное с минимальным надзором — лучший способ использовать это поколение LLM.

Выводы: от хаоса к управляемой автономии

Построить надёжный workflow-sandbox вокруг Claude Code — это не разовая настройка, а итеративный процесс. Ключевые принципы:

Изолируйте на уровне ОС — sandbox через macOS Seatbelt, Linux bubblewrap или Docker-контейнер
Используйте хуки для детерминизма — то, что должно выполняться всегда, не доверяйте промптам
MCP осторожно — каждый новый сервер ест контекст; подключайте только необходимые
Plan Mode перед каждой крупной задачей — хороший план кратно увеличивает качество результата
Гибридная архитектура — агентные шаги для творческой работы, детерминированный код для pipeline
Управляйте контекстом — 60% максимум, чистите между фазами, распределяйте по субагентам

Создатель Claude Code сам говорит: нет единственно правильного способа использовать Claude Code — он намеренно строится так, чтобы его можно было использовать, настраивать и взламывать как угодно. Каждый член команды Claude Code использует его по-своему.

Это и есть главная свобода — и главная ответственность. Ваш идеальный sandbox существует, но его нужно построить самостоятельно.