OpenAI показала, как построила безопасную песочницу Codex для работы в Windows

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

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

Либо подтверждать почти каждую команду, включая простое чтение файлов, либо включать Full Access и фактически доверять агенту тот же уровень прав, что у самого разработчика. Для Codex это особенно чувствительно: агент работает через CLI, IDE и desktop-приложение, может запускать тесты, редактировать код, создавать Git-ветки и вызывать обычные инструменты разработки. OpenAI сначала проверила стандартные механизмы изоляции Windows, но ни один не подошёл без серьёзных компромиссов.

AppContainer даёт сильную границу безопасности, но рассчитан на заранее описанное приложение, а не на открытый набор сценариев с Git, Python, пакетными менеджерами и сторонними бинарниками. Windows Sandbox оказался слишком «отдельным» миром: Codex нужно работать с реальным checkout пользователя, а не с одноразовой виртуальной машиной, плюс этот режим недоступен на Windows Home. Механизм уровней целостности тоже выглядел красиво только на бумаге, потому что менял модель доверия для реальной файловой системы хоста.

Первая схема защиты Первый рабочий прототип OpenAI собрала без требований к правам администратора.

В нём использовались синтетический SID и write-restricted token — специальный токен, который позволяет записывать данные только туда, где одновременно совпадают обычные права пользователя и отдельное разрешение для sandbox. Так Codex мог читать почти везде, но писать только в чётко заданные корни проекта. создавался отдельный SID `sandbox-write` этому SID выдавались права на запись, выполнение и удаление в текущем рабочем каталоге и в `writable_roots` * внутри этих каталогов можно было отдельно запретить запись в `.

git`, `.codex` и `.agents` * каждая команда запускалась с ограниченным токеном, где учитывались `Everyone`, SID текущей сессии и `sandbox-write` С файлами подход сработал неплохо, но сеть осталась слабым местом.

Команда пыталась «ломать» типовые сетевые пути через переменные окружения вроде `HTTPS_PROXY`, `ALL_PROXY` и `GIT_SSH_COMMAND`, а также через подмену stub-бинарников для `ssh` и `scp`. Для обычных Git-команд и установщиков пакетов этого часто хватало, но защита была скорее рекомендательной: любой процесс мог проигнорировать переменные среды, обойти PATH или открыть сокет напрямую.

Как устроен релиз

Из-за сетевых ограничений OpenAI ушла от идеи полностью безадминской песочницы и перешла к текущей, более жёсткой схеме. Теперь на этапе настройки Codex создаёт двух локальных пользователей: `CodexSandboxOffline` для процессов без сети и `CodexSandboxOnline` для сценариев, где доступ нужен. Команды всё ещё запускаются с ограниченным токеном, но уже не от имени реального пользователя, а от имени специального sandbox-пользователя, на которого можно навесить правила Windows Firewall.

Это потребовало отдельного setup-процесса. Он создаёт синтетический SID, заводит sandbox-аккаунты, шифрует их credentials через DPAPI и выставляет firewall-правила, которые блокируют исходящий трафик для offline-пользователя. Параллельно система выдаёт sandbox-пользователям права на чтение в типовых директориях вроде `C:\Users\<real-user>`, `C:\Windows`, `C:\Program Files` и `C:\ProgramData`, иначе агент не смог бы даже нормально читать пользовательские файлы и инструменты.

Часть ACL-настройки при этом выполняется асинхронно, чтобы не задерживать первичную установку. Отдельная проблема возникла на границе запуска процессов. Выяснилось, что `codex.

exe` не может надёжно пройти весь путь от входа под sandbox-пользователем до `CreateProcessAsUserW(...)` из контекста реального пользователя. Поэтому OpenAI вынесла запуск команд в отдельный бинарник `codex-command-runner.

exe`: сначала `codex.exe` стартует его как sandbox-пользователя, а уже runner внутри своей сессии создаёт restricted token и запускает конечный дочерний процесс. В финальной архитектуре участвуют четыре слоя: сам `codex.

exe`, elevated setup-бинарник, command runner и целевой процесс.

Что это значит

Для Windows-разработчиков это важный сдвиг: локальные coding-агенты становятся не только удобнее, но и предсказуемее с точки зрения безопасности. OpenAI фактически показала, что для агентного кодинга на Windows не хватает одного «волшебного» API, и проблему приходится решать комбинацией ACL, токенов, отдельных пользователей, firewall-правил и дополнительных бинарников. Это повышает сложность реализации, но делает модель работы Codex ближе к реальным требованиям команд, которые хотят автоматизировать рутину без полного отказа от контроля.