Codex Automation Sandbox и Unsafe Mode: изоляция агентов и безопасность в Windows

Вопрос, который командам стоит задавать о любом coding-агенте, — не «насколько умна модель?», а: что агент реально может исполнить на машинах разработчиков и что мешает ему пойти дальше? Инженерный пост OpenAI о создании Codex Windows Sandbox делает этот вопрос конкретным — а зафиксированные в нём архитектурные решения напрямую релевантны любой команде, разворачивающей Codex, Claude Code, OpenCode или любой другой coding-агент с локальным исполнением.

Что произошло

OpenAI опубликовала подробный инженерный пост о том, как Codex теперь реализует изоляцию процессов на уровне ОС в Windows. Проблема была реальной: до этой работы у пользователей Windows было два варианта — либо подтверждать почти каждую команду агента вручную (что убивает идею автоматизации), либо включать режим Full Access и давать агенту работать без ограничений (что убивает идею безопасности). У macOS и Linux уже были штатные примитивы sandbox на уровне ОС (Seatbelt и seccomp/bubblewrap соответственно); у Windows — нет.

Команда оценила три существующих механизма Windows и отвергла все три:

• AppContainer — сильная изоляция, но рассчитан на узко очерченные приложения с заранее известным набором разрешений. Codex же гоняет открытые devloper-workflow (shells, Git, Python, build-инструменты, произвольные бинарники) — AppContainer тут не той формы.
• Windows Sandbox — одноразовая лёгкая виртуалка с сильной изоляцией, но требует setup/teardown, недоступна в SKU Windows Home и не может работать с реальным checkout пользователя без сложного host/guest-моста.
• Mandatory Integrity Control (MIC) labeling — пометив workspace как low-integrity, можно разрешить Codex туда писать, но одновременно этот workspace становится low-integrity-стоком для любого low-integrity-процесса в системе. Это сдвиг модели доверия гораздо шире, чем задумывалось.

Итоговая архитектура использует write-restricted process tokens и синтетические Security Identifier (SID), чтобы ограничить, куда sandbox-процесс может писать, — без необходимости поднимать права администратора. Каталог workspace получает таргетированные ACL-записи, разрешающие запись sandbox SID, а остальная файловая система остаётся защищённой restricted token. Сетевой доступ контролируется отдельным механизмом, наложенным сверху.

Почему это важно для AI-инженерных команд

Архитектурная история здесь обобщается далеко за пределы Windows. Большинство команд, разворачивающих локальные coding-агенты, не отвечали явно на тот же вопрос, который пришлось решать команде Codex: какова граница процесса агента на уровне ОС?

На macOS Codex использует Seatbelt, который большинство инженеров принимают как данность. На Linux профили seccomp/bubblewrap существуют, но их нужно валидировать под конкретный пакетный менеджер и build-цепочку. В Windows, как показывает этот пост, разрыв был настолько широким, что потребовал отдельной реализации.

Практические следствия для инженерных команд:

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

2. Full Access — это решение уровня корпоративной политики, а не просто удобный тумблер. OpenAI напрямую называет Full Access небезопасным режимом. Если ваши разработчики на Windows пользовались Full Access, потому что это был единственный практичный выход из непрерывных подтверждений, окно этого риска теперь закрылось — но значит, какие-то команды до сих пор гоняли близкие к production нагрузки фактически без принуждения границ записи.

3. Безопасный sandbox не должен требовать прав администратора. Архитектура Codex намеренно обходится без admin-прав. Если оцениваемый вами coding-агент требует elevated permissions просто для разворачивания sandbox, это содержательный сигнал безопасности. Sandbox без elevation достижим — и должен быть базовым ожиданием.

4. Персистентность сессии и родословная процессов имеют значение. Codex sandbox применяется с момента запуска процесса и наследуется всем деревом процессов. Любой subprocess, порождённый агентом, наследует те же ограничения. Это правильная модель, но в ней легко ошибиться: sandbox, применяющийся к родителю, но не наследуемый детьми, даёт ложное чувство защищённости.

Угол зрения router/operator

Для команд, использующих routing-gateway для маршрутизации запросов coding-агентов через разные backend-модели, вопрос sandbox отличается от вопроса routing — но они взаимодействуют.

Переключение провайдера меняет execution harness, а не локальный sandbox. Когда вы маршрутизируете запрос в формате Codex через другую backend-модель через OpenAI-совместимый gateway, локальный harness Codex по-прежнему работает со своим sandbox. Меняется endpoint модели; локальное окружение исполнения — нет. Это значит, что архитектура sandbox — свойство harness, а не model. Если вы меняете модель, но оставляете harness, контракт sandbox держится.

У не-Codex harness может быть другой контракт sandbox. Если ваша команда использует Claude Code, OpenCode или кастомный harness coding-агента, реализация sandbox специфична для этого harness. Claude Code на macOS использует Seatbelt в дефолтном режиме; поведение в Windows — отдельный профиль. Команды с мульти-harness окружением (разные разработчики используют разные инструменты, нацеленные на одну и ту же модель через gateway) должны независимо аудитить контракт sandbox по каждому harness.

Governance требует большего, чем видимость на уровне модели. Большинство AI gateway фиксирует, на какую модель ушёл запрос и сколько токенов потрачено. Они не фиксируют, к каким файлам на локальной машине разработчика обратился агент и что он изменил. Эта видимость живёт на уровне harness, а не routing. Если ваш governance-постулат требует аудитируемости действий агента в файловой системе, ответ — это логирование на уровне harness (например, логи approvals в Codex), а не телеметрия routing-слоя.

За чем следить

• Аудитируйте парк Windows-разработчиков. Если разработчики пользовались режимом Codex Full Access как обходным путём, самое время сбросить эту конфигурацию. Новый sandbox должен сделать дефолтный режим жизнеспособным в Windows без непрерывных подтверждений.

• Пересмотрите допущения о sandbox при оценке новых coding-агентов. Для любого агента с локальным исполнением задавайте вопросы: (а) какой механизм ОС принуждает границы записи? (б) требует ли он elevation? (в) распространяется ли ограничение на дочерние процессы? (г) что происходит со сценариями сетевого доступа? Это теперь аудитируемые вопросы, а не теоретические.

• Относитесь к обновлению версий harness как к surface безопасности. Когда Codex, Claude Code или подобные инструменты выкатывают обновления harness, эти обновления могут менять реализацию sandbox. Апдейт версии, сдвигающий механизмы изоляции, — это изменение политики безопасности, а не просто bump версии. Относитесь соответствующе.

• Используйте ACL уровня конкретного workspace, а не широкое доверие к каталогам. Архитектура Codex изолирует доступ на запись к конкретному каталогу workspace, а не к широкому классу каталогов. Это правильный паттерн. При настройке workspace для агента давайте права записи на конкретные нужные ему каталоги, а не на корни вверх по дереву.

TheRouter маршрутизирует API-запросы к моделям между провайдерами и фиксирует потребление токенов для биллинговой сверки. Операции coding-агентов с файловой системой локальны для машины разработчика и лежат вне области routing API. Поэтому вопрос governance — двухслойный: routing-gateway отвечает за политику доступа к моделям, конфигурация harness — за политику локального исполнения. Оба слоя должны быть сконфигурированы явно — один не заменяет другой.