Запустите Codex или кодирующего агента в безопасной песочнице

Запускайте кодирующего агента в песочнице, предоставляя ему ограниченное рабочее пространство репозитория, контролируемый путь выполнения команд в терминале, явные разрешения на файлы, политики сети и установки пакетов, изолированные секреты, журналы команд, артефакты и четкий путь утверждения для изменений с высоким риском перед слиянием или развертыванием. Этот шаблон работает независимо от того, является ли агент стилем Codex, подключен к IDE, запускается CI или встроен в вашу собственную платформу разработчика: модель может планировать и редактировать, но песочница решает, к чему она может прикасаться, что запускать, что загружать и какие доказательства получает рецензент.

Что такое песочница кодирующего агента?

Песочница кодирующего агента — это изолированная среда выполнения, где AI-система может просматривать код, редактировать файлы, запускать команды терминала, устанавливать зависимости, если это разрешено политикой, выполнять тесты, запускать серверы предварительного просмотра и возвращать проверяемый diff без предоставления широкого доступа к машине разработчика или производственной среде.

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

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

• Выделенное рабочее пространство для каждой задачи или сессии.
• Известное состояние репозитория и ветка.
• Интерфейс выполнения команд с утверждением для рискованных операций.
• Политика установки пакетов для npm, pip, cargo, apt и подобных инструментов.
• Правила сетевого исходящего трафика для реестров, документации, API и доступа к предварительным просмотрам.
• Секреты, ограниченные задачей и скрытые из журналов, где это возможно.
• Захваченные stdout, stderr, коды выхода, изменения файлов, сгенерированные артефакты и URL предварительных просмотров.
• Шлюз проверки перед слиянием, развертыванием или внешним релизом.

Вот почему «запустить Codex в песочнице» следует понимать как инфраструктурный шаблон, а не как один флаг CLI или интеграцию с одним вендором. Сам Codex CLI документирован как кодирующий агент, который работает локально на вашем компьютере, а документация OpenAI по Codex описывает терминально-ориентированный рабочий процесс. Если вы управляете таким агентом для команды, CI-системы или продуктового рабочего процесса, окружающая среда выполнения становится плоскостью управления.

Архитектура песочницы кодирующего агента

Слой	Ответственность	Вопросы, на которые нужно ответить
Интерфейс агента	Превращает намерение пользователя в планы, редактирование файлов, вызовы инструментов и краткие обзоры	Какая модель или кодирующий агент используется? Как управляются промпты, контекст и схемы инструментов?
Менеджер рабочего пространства	Создает песочницу, проверяет репозиторий, устанавливает ветку и монтирует разрешенные файлы	Каждая ли задача изолирована? Известен ли базовый коммит? Можно ли сбросить рабочее пространство?
Исполнитель терминала	Выполняет утвержденные команды и передает результаты обратно агенту	Какие команды разрешены автоматически, требуют утверждения или заблокированы?
Слой политик	Контролирует область файловой системы, секреты, сетевой исходящий трафик, установку пакетов, ограничения времени выполнения и очистку	Может ли агент загружать пакеты? Может ли он обращаться к публичному интернету? Может ли он читать учетные данные?
Слой доказательств	Хранит журналы, diff’ы, результаты тестов, предварительные просмотры и артефакты	Может ли рецензент восстановить произошедшее, не доверяя сводке модели?
Шлюз проверки	Требует шага утверждения человеком или доверенной автоматизацией перед слиянием, публикацией или развертыванием	Кто утверждает рискованные изменения? Какие проверки должны быть пройдены в первую очередь?

На практике одна платформа может объединять несколько из этих слоев. Архитектура все равно важна, потому что она сохраняет честность продуктовых решений. Если инструмент предоставляет агенту терминал, но не может показать журналы команд, diff’ы файлов или политику исходящего трафика, он может быть удобен для прототипирования, но недостаточен для производственной проверки.

Как должен работать доступ к терминалу в песочнице кодирующего агента?

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

Хорошая модель терминала состоит из трех частей.

Во-первых, определите классы команд. Безопасные команды только для чтения, такие как ls, sed, rg, git diff, и команды статуса тестов часто могут выполняться автоматически. Команды сборки и тестирования, такие как npm test, pytest, cargo test и npm run build, могут быть разрешены с тайм-аутами. Деструктивные команды или команды, влияющие на внешнюю среду, такие как rm -rf, git push, gh pr merge, CLI развертывания, публикация пакетов, миграция базы данных или изменение облачных ресурсов, должны требовать явного утверждения или быть полностью заблокированными.

Во-вторых, передавайте результаты с структурой. Агент и рецензент должны видеть команду, рабочий каталог, время начала, код выхода, stdout, stderr, состояние тайм-аута и политику усечения вывода. Скриншот терминала недостаточен; система должна сохранять журналы в машиночитаемом формате.

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

Изоляция репозитория и контроль веток для изменений агента

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

Для командных рабочих процессов начинайте каждую задачу с известного URL репозитория, базовой ветки и SHA коммита. Создайте ветку задачи или отсоединенное рабочее пространство. Храните изменения пользователя отдельно от изменений агента и фиксируйте точный diff перед проверкой. Если песочница поддерживает постоянные сессии, сохраняйте рабочее пространство намеренно; не полагайтесь на случайное состояние процесса.

Стандартный шаблон выглядит так:

1. Create isolated workspace for task-123.
2. Check out repository at main@<base_sha>.
3. Create branch agent/task-123.
4. Run dependency install according to policy.
5. Let the agent inspect, edit, test, and iterate.
6. Capture git diff, test output, generated artifacts, and preview URL.
7. Open a pull request or hand the patch to a human reviewer.
8. Tear down or archive the workspace according to retention policy.

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

Политики команд, пакетов и сети для песочниц кодирующих агентов

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

Практическая политика — не «никогда не устанавливать пакеты». Она заключается в том, чтобы «устанавливать пакеты только через известные пути с ведением журнала и областью действия».

Контроль	Практическая реализация
Менеджеры пакетов	Определите, какие менеджеры пакетов доступны в зависимости от языка и типа репозитория.
Доступ к реестрам	Разрешите утвержденные реестры; блокируйте произвольные источники пакетов, если задача в них не нуждается.
Lock-файлы	Предпочитайте существующие lock-файлы и воспроизводимые команды установки.
Сценарии после установки	Решите, могут ли сценарии жизненного цикла выполняться автоматически или требуют утверждения.
Системные пакеты	Относитесь к установке системных пакетов через apt, brew и OS как к более рискованным, чем установка зависимостей проекта.
Кэши	Используйте контролируемые кэши пакетов, когда нужна скорость и воспроизводимость.
Журналирование	Сохраняйте имена пакетов, версии, URL реестров, контрольные суммы, если доступны, и вывод установки.

Политика сети должна быть аналогично явной. Кодирующему агенту может потребоваться читать публичную документацию, вызывать staging API, загружать пакет или предоставлять локальный предварительный просмотр. Это отличается от неограниченного доступа в интернет. Разделяйте исходящие загрузки пакетов, веб-серфинг, вызовы API, доставку вебхуков и входящий трафик предварительного просмотра. Если ваш продукт обрабатывает чувствительный код или данные, спросите, покрываются ли DNS, журналы прокси и зеркала реестров той же политикой, что и HTTP-трафик.

Секреты, журналы и аудиторские следы для рабочих пространств агента

Секреты должны быть ограничены до минимальной полезной поверхности. Кодирующему агенту обычно не нужны производственные учетные данные. Ему может потребоваться токен Git только для чтения, токен реестра пакетов, ключ staging API или токен для развертывания предварительного просмотра. Каждый должен быть ограничен задачей, по возможности ограничен по времени и недоступен командам, которые в нем не нуждаются.

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

Для аудиторских следов храните больше, чем финальный патч:

• Запрос пользователя и метаданные задачи.
• URL репозитория, базовый коммит, ветка и финальный коммит или diff.
• Команды: запрошенные, утвержденные, заблокированные и выполненные.
• Вывод команд, коды выхода и тайм-ауты.
• Чтения и записи файлов, когда платформа может их захватить.
• Записи о сети и загрузке пакетов на уровне, поддерживаемом вашей политикой.
• URL предварительных просмотров и пути сгенерированных артефактов.
• Человеческие утверждения и решения о слиянии.

Это не бюрократия. Это то, как рецензент отличает реальное исправление от правдоподобной истории.

Diff’ы, предварительные просмотры и шлюзы проверки перед слиянием

Самый полезный результат от кодирующего агента — это проверяемый набор изменений. Это означает, что песочница должна создавать те же артефакты, которые осмотрительный инженер ожидал бы от pull request:

• Сфокусированный diff.
• Тесты или команды сборки, которые были выполнены.
• Оставшиеся сбои.
• Скриншоты, URL предварительных просмотров или загружаемые файлы, когда изменился UI или сгенерированные ресурсы.
• Краткое объяснение предполагаемого изменения поведения.

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

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

Стратегия очистки и сброса для длительных сессий агента

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

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

Определите очистку для:

• Фоновых процессов и открытых портов.
• Временных файлов и результатов сборки.
• Кэшей пакетов и загруженных архивов.
• Секретов, ограниченных задачей.
• Журналов и артефактов.
• Веток или рабочих деревьев, которые были заменены.

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

Где Novita Agent Sandbox вписывается в этот рабочий процесс

Novita Agent Sandbox предназначен для инфраструктуры агентов, где выполнение кода, автоматизация браузера, рабочие процессы в стиле computer-use, анализ данных, оценки и длительные рабочие процессы агентов требуют изолированной среды выполнения. Документация Novita Agent Sandbox описывает продукт как среду с состоянием для выполнения рабочих нагрузок агентов с путями SDK и CLI для работы с жизненным циклом песочницы, файлами, командами, сессиями браузера и связанными примитивами рабочего процесса.

Для команд, уже использующих API моделей Novita AI, слой песочницы может сократить разрыв между инференсом модели и выполнением действий. Модель может рассуждать, вызывать инструменты и планировать изменения кода; песочница может предоставить изолированное рабочее пространство, где эти действия выполняются, журналируются, просматриваются и проверяются.

Используйте консервативные границы продукта при проектировании рабочего процесса:

• Относитесь к Novita Agent Sandbox как к среде выполнения, а не как к всеобъемлющей гарантии безопасности.
• Держите секреты, установку пакетов, исходящий трафик и действия по публикации за своей собственной политикой.
• Проверяйте текущие SDK, CLI, цены и лимиты учетной записи из документации Novita перед жестким кодированием их в производственную автоматизацию.
• Оценивайте границы изоляции, совместимость со сторонними агентами и требования соответствия относительно вашей собственной политики, прежде чем полагаться на любую песочницу в производстве.

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

Контрольный список реализации песочницы кодирующего агента

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

Область	Минимальный производственный вопрос
Рабочее пространство	Получает ли каждая задача ограниченную файловую систему и известный базовый коммит репозитория?
Ветвление	Изолированы ли изменения агента в ветке или патче, которые могут проверить рецензенты?
Терминал	Журналируются ли команды с рабочим каталогом, выводом, кодом выхода и тайм-аутом?
Утверждение	Какие команды выполняются автоматически, требуют утверждения или заблокированы?
Пакеты	Воспроизводима ли установка зависимостей и журналируется ли она?
Сеть	Разделен ли исходящий трафик на загрузку пакетов, просмотр документации, вызовы API и доступ к предварительным просмотрам?
Секреты	Ограничены ли учетные данные задачей и скрыты ли из журналов?
Предварительные просмотры	Явно ли указаны порты предварительного просмотра и легко ли их закрыть?
Артефакты	Прикреплены ли сгенерированные файлы, скриншоты, отчеты и журналы к проверке?
Постоянность	Является ли приостановка/возобновление сессии намеренным, с владельцем и сроком действия?
Очистка	Удаляются ли процессы, порты, временные файлы, секреты и устаревшие рабочие пространства?
Проверка	Утверждает ли человек слияние, публикацию или развертывание для рискованных изменений?

Если ваша текущая настройка не может ответить на несколько из этих вопросов, оставьте рабочий процесс в статусе прототипа. Агент все еще может быть полезен, но он не должен получать широкий доступ к репозиторию, сети или учетным данным.

FAQ

Могу ли я запустить сам Codex внутри облачной песочницы?

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

Достаточно ли Docker для песочницы кодирующего агента?

Docker может быть полезен для локальной разработки, задач CI и повторяемых сред, но «достаточно» зависит от вашей модели угроз. Спросите, что разделяет ядро, какие монтирования файлов существуют, как контролируется исходящий сетевой трафик, раскрываются ли секреты контейнеру и как будут обрабатываться побеги или компрометация зависимостей. Для чувствительных рабочих нагрузок команды безопасности часто оценивают более строгие границы изоляции и более жесткий контроль исходящего трафика.

Должен ли кодирующий агент иметь доступ в интернет?

Только когда задача в этом нуждается, и только через политику, которую вы можете объяснить. Просмотр документации, доступ к реестру пакетов, вызовы staging API и произвольный серфинг — это разные разрешения. Журналируйте, что загрузил агент, сохраняйте воспроизводимость установки пакетов и избегайте предоставления производственного сетевого доступа для сессии кодирования общего назначения.

На что должен смотреть рецензент перед слиянием кода, сгенерированного агентом?

Проверьте diff, выполненные команды, вывод тестов/сборки, изменения зависимостей, сгенерированные артефакты, поведение предварительного просмотра и любые пропущенные проверки. Уделите особое внимание аутентификации, разрешениям, обработке данных, сетевым вызовам, миграциям, сценариям установки и секретам.

Как Novita помогает с песочницами кодирующих агентов?

Novita Agent Sandbox предоставляет изолированную среду выполнения агента для рабочих нагрузок, таких как выполнение кода, автоматизация браузера, задачи в стиле computer-use, анализ данных, оценки и длительные рабочие процессы. Сочетайте его с явными политиками репозитория, команд, пакетов, сети, секретов и проверки при построении рабочего процесса кодирующего агента.

Рекомендуемые статьи

• Требования к песочнице для кода, сгенерированного ИИ, для производственных приложений
• Серверы MCP в изолированных песочницах: компромиссы файловой системы, секретов и сети
• Firecracker для песочниц ИИ-агентов: преимущества, ограничения и вопросы оценки
• Создайте ИИ-аналитика данных с изолированным Python и контролируемым доступом к пакетам