Codex Sandbox: режимы, разрешения и безопасная проверка

Codex Sandbox ограничивает команды агента на уровне операционной системы: запись в файлы, сеть и выход за рабочую область. Для локальной разработки подходит workspace-write с согласованием по запросу, для изучения проекта read-only. Полный доступ нужен только для заранее понятного действия вне этих границ.

Песочница и согласование отвечают за разные вещи

Песочница задаёт техническую границу, а политика согласований определяет, когда Codex остановится и попросит разрешение. OpenAI разделяет эти механизмы в руководстве по безопасному запуску Codex.

• read-only разрешает анализировать доступные файлы, но не менять их в обычном ходе задачи.
• workspace-write разрешает чтение и правки внутри рабочей папки, но сохраняет ограничения для внешних путей и сети.
• danger-full-access снимает основную изоляцию. Это не ускоритель для обычной задачи, а отдельное решение с более высоким риском.
• approval_policy управляет остановками на запрос разрешения. Разрешение один раз не означает, что действие стало безопасным навсегда.

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

Правило выбора: сначала сузьте рабочую область и действие, затем дайте минимальные права, при которых задача проходит. Не начинайте с полного доступа только потому, что первый запуск встретил блокировку.

Карта результата до выбора режима

До запуска запишите семь пунктов, чтобы определить допустимые права.

• Исходные условия: точная папка проекта, текущее состояние Git, доступные команды и наличие тестовых данных.
• Результат: какие файлы или отчёты должны появиться и какое поведение должно измениться.
• Обязательные шаги: чтение, правка, локальная команда, доступ к сети или внешний инструмент.
• Проверка: команда теста, diff, контрольная сумма, ручной сценарий или независимое чтение результата.
• Частые сбои: неверный рабочий каталог, запись во внешний кэш, скачивание зависимости, ожидание согласования.
• Ограничения: секреты, персональные данные, продакшен, платёж, публикация и необратимые изменения.
• Случай отказа: если нет точки возврата или независимой проверки, агент должен подготовить план, а не выполнять изменение.

Постоянные параметры разобраны в настройке Codex. AGENTS.md объясняет агенту процесс, а песочница технически ограничивает доступ. Эти механизмы не заменяют друг друга.

По теме: Codex Security: что это и как безопасно начать проверку кода

Как выбрать режим без лишнего риска

Выбор можно свести к наблюдаемому действию. Если действие не требуется, право на него тоже не требуется.

1. Нужно только объяснение, обзор кода или план: запустите read-only.
2. Нужны правки и локальные тесты внутри проекта: выберите workspace-write и согласование on-request.
3. Нужно скачать зависимость: оставьте файловую границу прежней и отдельно разрешите только ожидаемый сетевой шаг, если источник проверен.
4. Нужно записать файл вне проекта: сначала измените путь вывода на подпапку рабочей области. Расширяйте writable root только если это невозможно по устройству задачи.
5. Нужно изменить систему или рабочий сервер: остановитесь, разделите подготовку и внешнее действие, сделайте резервную копию и запросите отдельное подтверждение.
6. Полный доступ рассматривайте только после того, как можете назвать точную команду, её последствия, способ отката и признак успеха.

Для большинства задач достаточно workspace-write. Стандартная граница ограничивает запись рабочей областью и сетевой доступ, но не делает любую команду внутри проекта безвредной. Принцип описан в материале OpenAI о песочнице Windows.

Проверка границ за пять минут

Создайте отдельный тестовый проект без секретов и выберите стандартный режим записи в рабочую область.

1. Попросите создать sandbox-check/inside.txt со словом ok. Файл должен появиться внутри проекта.
2. Попросите показать содержимое созданного файла и удалить его. Это проверяет обратимую запись, чтение и удаление в разрешённой области.
3. Попросите только составить команду для создания файла в соседней папке, не выполнять её. Сначала оцените путь и последствия.
4. Если вы сознательно запускаете проверку выхода за границу, используйте безвредное уникальное имя в специально созданной тестовой папке. Ожидайте блокировку или запрос разрешения.
5. Попросите получить заголовок с тестового адреса. При закрытой сети ожидайте блокировку или согласование, а не успешный тихий выход в интернет.
6. Просмотрите журнал действий, затем удалите тестовый проект штатным способом. Не сохраняйте постоянное правило разрешения ради этого теста.

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

По теме: ИИ-агенты для VS Code: как выбрать и проверить в 2026

Почему команда блокируется

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

• Установщик пакетов не работает: ему может требоваться сеть и запись в глобальный кэш. Сначала используйте уже установленные зависимости или проектный кэш.
• Тест падает с Permission denied: найдите точный путь записи. Перенаправьте отчёт, снимок или кэш внутрь рабочей области.
• Git-команда не меняет служебные файлы: защищённые каталоги могут оставаться только для чтения. Не обходите защиту ради обычной правки кода.
• Команда ждёт бесконечно: проверьте, не открыт ли невидимый интерактивный запрос и не ожидается ли согласование.
• Локальный сервер не стартует: ему может быть запрещено слушать порт. Для проверки используйте штатный механизм приложения или отдельно разрешённый локальный bind.
• Агент просит полный доступ после первого сбоя: запросите точную команду, путь и адрес. Часто достаточно одного узкого разрешения или другого каталога вывода.

Диагностируйте по одному уровню: рабочий каталог, путь записи, сеть, порт, внешний инструмент, затем политика согласований. Общие ошибки запуска разобраны в статье про сбои Codex.

Чего песочница не гарантирует

Песочница не проверяет смысл правки. Агент может удалить важный файл внутри разрешённой папки, испортить конфигурацию или раскрыть доступный секрет. Нужны Git, резервная копия, тест и ручной просмотр diff.

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

Если задаче нужны повторяемые инструкции, сначала опишите их в AGENTS.md или навыке. Руководство по Codex Skills помогает отделить рабочий процесс от прав доступа. Навык объясняет последовательность, но расширять песочницу он не должен самовольно.

По теме: Codex Plugins: что это и как пользоваться плагинами

Когда sandbox не решает задачу

Sandbox не является единственной защитой для платежей, удаления, публикации, управления доступом и продакшена. Нужны отдельные права, тестовый контур, резервная копия, журнал и подтверждение перед действием.

Он также не исправляет неизвестную команду. Если вы не понимаете, что делает скрипт, безопаснее попросить анализ в read-only, затем проверить источник и только после этого запускать в отдельной тестовой среде.

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

Что значит workspace-write в Codex?

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

Почему интернет не работает внутри Codex?

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

Можно ли выключить песочницу навсегда?

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

Нужен ли sandbox, если проект хранится в Git?

Да. Git помогает увидеть и откатить файловые изменения, а песочница ограничивает доступ процесса к путям и сети. Эти механизмы дополняют друг друга.