Codex Sandbox ограничивает доступ команд к файлам и сети; для рабочей папки режим выбирают по нужным действиям и проверяют на разрешённой операции и ожидаемом отказе. Отдельная политика разрешений определяет, когда Codex запрашивает согласие человека. Перед работой зафиксируйте корни доступа, сетевые правила и сценарий приёмки, чтобы команда понимала фактические границы сессии.
Два уровня контроля
У локального Codex два разных механизма: песочница задаёт техническую границу команд, политика разрешений определяет момент запроса согласия. Один механизм нельзя оценивать по настройке другого.
Команда может работать с репозиторием через Codex CLI или расширение IDE. В этих вариантах ограничения команд реализуются средствами операционной системы. У облачного Codex собственная изолированная среда и отдельные сетевые правила; значения локального профиля нельзя автоматически переносить на облачный запуск. Перед настройкой запишите место выполнения, рабочую папку и владельца политики. Для описания повседневного командного цикла полезен разбор Codex в команде разработки; здесь внимание сосредоточено на границе доступа команд.
Песочница отвечает на вопрос, какие операции доступны процессу: чтение, запись в разрешённые корни, обращение к сети. Политика согласований отвечает на другой вопрос: при каких действиях Codex останавливается и спрашивает разрешение. В локальном типовом сочетании workspace-write с on-request агент редактирует файлы рабочей папки, а выход за её пределы требует отдельного решения. При корпоративных ограничениях часть запросов может быть отклонена без возможности расширения прав.
Это разделение важно для руководителя проекта. Согласие в диалоге сохраняет запрет на путь, когда верхняя политика исключает расширение. Запись внутри рабочей папки обычно выполняется без отдельного вопроса на каждый файл. Человек утверждает границы заранее, а затем проверяет конкретный запрос на расширение доступа. Модель может предложить действие, но фактический допуск проверяют средство исполнения и действующая политика. Основные термины приведены в официальной документации OpenAI по безопасности Codex.
Режимы доступа
Начните с задачи, а затем выберите минимальные права. Для чтения кода и подготовки плана хватает read-only. Для правок в активном репозитории подходит workspace-write при проверенном наборе корней. Режим полного доступа снимает локальную границу песочницы и для обычного разбора проекта избыточен. Название режима скрывает часть деталей: на итог влияют разрешённые корни, настройки сети и правила организации.
| Режим | Что доступно локальной команде | Когда выбирать |
|---|---|---|
| read-only | Чтение доступных файлов и команды в режиме без записи. | Просмотр кода, план изменений, проверка структуры. |
| workspace-write | Запись в активные рабочие корни и системные временные каталоги; отдельные защищённые пути остаются только для чтения. | Разработка в согласованной папке с проверкой изменений. |
| danger-full-access | Локальная песочница снята; объём фактического доступа зависит также от учётной записи и внешних политик. | Для описанного маршрута разработки режим избыточен. |
Проверьте текущие границы через команду /status и согласованный профиль разрешений. Рабочая папка может включать временные каталоги, поэтому слово «workspace» шире одного каталога репозитория. В стандартном workspace-write часть внутренних путей остаётся защищённой: например, .git, .agents и .codex внутри разрешённого корня доступны только для чтения. Проверяйте право на изменение служебных файлов и соседних папок отдельно.
Отдельно уточните чтение. Ограничение записи рабочей папкой допускает чтение некоторых файлов вне неё: фактический доступ зависит от профиля и системных прав. Если задача содержит секреты или соседние проекты, настройте специальный профиль и правила доступа к данным силами администратора. Логика разграничения и профили описаны в официальном руководстве по разрешениям. Самого наличия файла в доступной области недостаточно для включения его содержимого в запрос или отчёт.
Сеть и согласие
Для локального workspace-write документация OpenAI указывает отключённый по умолчанию доступ команд к сети. Включение сетевого флага меняет техническую границу; настройка списка доменов требует отдельной политики исходящих соединений. Поэтому перед запуском выпишите, какие операции действительно требуют сети: установка зависимостей, обращение к документации либо тест внешнего API. Если все материалы уже в репозитории, оставьте сетевой доступ закрытым.
Политика on-request позволяет Codex запросить согласие на действие за пределами текущей песочницы, когда такой запрос разрешён системой. Запрос должен описывать конкретную команду, целевой путь или адрес и причину. Ответственный человек сопоставляет запрос с задачей, проверяет ожидаемый результат и принимает решение. Отказ оставляет прежнюю границу. Если сеть или расширение корней запрещены корпоративной политикой, запрос оформляют как исключение у владельца политики; действующие требования сохраняют силу до его решения.
Сетевые команды и веб-поиск проверяйте отдельно: у последнего собственные настройки. Программы, запущенные из shell, и подключённые приложения также проходят разные механизмы контроля. Перед пилотом укажите, какие инструменты вообще входят в задачу, а для остальных оставьте доступ закрытым. При работе с внешним API проверьте, какие данные уйдут из репозитория и кто имеет право отправлять их сервису. О том, как отдельно планировать корпоративное подключение, рассказывает материал о Codex API для компании.
Практическое правило для согласования: один запрос на расширение должен иметь одну понятную цель. Если Codex предлагает одновременно запись за пределами проекта и сетевую отправку, разделите действия и оцените каждое по отдельности. Лог разрешений сохраняет основание решения, а diff показывает фактические изменения файлов. По одним словам модели нельзя считать операцию безопасной: разрешения применяет исполнитель, а спорное назначение операции подтверждает человек.
Хотите проверить границы Codex в вашем проекте?
Проверка границ
Проводите тест на специально подготовленных безвредных файлах. Владелец репозитория создаёт тестовый файл внутри разрешённого корня и отдельную тестовую цель вне разрешённых корней. Во втором месте нет секретов и рабочих данных; его назначение — показать отказ в записи. Перед запуском проверьте, что временный каталог находится за пределами доступных корней: системные временные пути часто имеют собственное разрешение на запись.
- Запишите текущий режим, политику согласований, рабочие корни и состояние сетевого доступа. Укажите, где выполняется Codex: CLI, IDE либо облако.
- Попросите прочитать и изменить разрешённый тестовый файл. Сохраните diff и убедитесь, что правка попала в ожидаемый корень.
- Попробуйте запись в подготовленную внешнюю цель через штатный механизм проверки. Зафиксируйте отказ или запрос на разрешение; завершите проверку до выдачи разрешения.
- Если сеть запрещена, используйте согласованный безвредный тестовый адрес и проверьте отказ командного доступа. Исключите реальные ключи, токены и клиентские данные.
- Повторите проверку для нужных ролей и сравните результат с утверждённой матрицей. Расхождения передайте владельцу политики до начала работы.
Для локального CLI у OpenAI описаны платформенные команды codex sandbox, позволяющие посмотреть поведение команды под песочницей. Используйте вариант своей операционной системы и тестовые файлы, без обращения к реальным закрытым каталогам. Исход теста оценивают по факту операции: появилось ли изменение внутри корня, сохранился ли внешний файл, был ли запрос на согласие и какой ответ вернула команда. Сообщения модели о «безопасном выполнении» недостаточно как доказательства.
Если ожидаемый отказ отсутствует, остановите пилот, сохраните минимум технических сведений без секретов и передайте их администратору. Возможные причины следует проверять по действующему профилю: ошибочно включённый корень, другая среда исполнения или более широкая политика. Исправление заключается в корректировке конфигурации уполномоченным человеком и повторном тесте. Обход ограничений ради завершения задачи создаст ложный результат приёмки.
Приёмка профиля
Матрица доступа должна помещаться в короткий рабочий документ: роль, режим, разрешённые корни, сетевые назначения, действия с запросом согласия и владелец исключения. Для задачи разработки обозначьте также тип файлов, которые агент вправе менять. Если это код и тесты, отдельно решите вопрос с конфигурацией сборки, миграциями и файлами развёртывания. Широкое право на запись в репозиторий само по себе оставляет публикацию и запуск в рабочей среде под отдельным контролем.
После настройки исполнитель проходит разрешённый сценарий и сценарий отказа. Ответственный разработчик просматривает diff, результаты тестов и список попыток пересечения границы. Администратор подтверждает, что фактические корни и сеть соответствуют утверждённому профилю. Владелец данных проверяет исключения, если в проекте есть закрытые материалы. Так приёмка связывает технический результат с конкретными людьми, вместо уверенного текста ответа агента.
Обновляйте матрицу при смене рабочего каталога, платформы, набора инструментов либо корпоративной политики. Те же проверки запускают после изменения профиля: сначала разрешённая запись, затем отказ на внешней цели и сетевой тест по утверждённому сценарию. Документируйте только необходимые сведения: режим и путь тестовой цели без содержимого секретных файлов. Для команды также полезно согласовать лимиты работы, о чём есть отдельный разбор распределения лимитов Codex; лимиты использования отличаются от границ доступа.
Выберите один репозиторий и задачу чтения либо правки. Сверьте /status, составьте матрицу разрешений и проведите тест разрешённой операции вместе с тестом отказа.
При переходе от отдельного репозитория к командной практике опишите эти проверки в плане внедрения. На странице внедрения ИИ в процессы компании можно обсудить состав работ и ответственность сторон. Критерий готовности прост: утверждённый профиль совпадает с наблюдаемым поведением, исключения имеют владельца, а спорные действия остаются на решении человека.