Создание безопасной и эффективной песочницы для обеспечения работы Codex на Windows | OpenAI

Дэвид Визен, член технического персонала

Когда я присоединился к команде разработчиков Codex в сентябре 2025 года, в Codex для Windows отсутствовала реализация песочницы, а это означало, что пользователям Windows приходилось выбирать между двумя неудовлетворительными вариантами при использовании агентов кодирования OpenAI:

1. Одобрение практически каждой команды (даже команд чтения), которую хотел выполнить программист, неэффективно и утомительно. Главное преимущество использования Codex заключается в том, что вам не нужно выполнять всю эту рутинную работу самостоятельно.
2. Включение режима полного доступа: позволяет Codex выполнять все команды без одобрения или ограничений, что устраняет препятствия за счет снижения контроля.

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

Codex по умолчанию работает с правами реального пользователя, то есть может делать всё, что может делать пользователь. Это мощный и потенциально опасный механизм. Модель программирования может указывать программе выполнять команды локально, от запуска тестов до чтения или редактирования файлов и создания ветки Git, поэтому режим по умолчанию Codex пытается найти правильный баланс между эффективностью и безопасностью. Этот режим по умолчанию позволяет Codex читать файлы практически где угодно и записывать файлы в вашем рабочем пространстве (т.е. в каталоге, где вы запускаете Codex), без доступа к интернету, если вы этого не укажете. Для достижения этого автоматического ограничения на запись файлов и доступ к сети в безопасных пределах Codex необходима изолированная среда, которая фактически обеспечивает соблюдение этих ограничений.

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

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

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

Там, где существующие инструменты Windows оказались неэффективными

Windows предлагает ряд инструментов и средств для изоляции. Хотя ни один из них в полной мере не соответствовал нашим требованиям, мы рассмотрели несколько потенциальных решений, а именно AppContainer, Windows Sandbox и маркировку Mandatory Integrity Control.

AppContainer

• Что: AppContainer — это встроенная песочница Windows, модель изоляции на основе возможностей, созданная для приложений, которые заранее точно знают, к чему им нужен доступ.
• Почему : Привлекательность заключается в том, что это предлагает реальные ограничения операционной системы, а не ограничения, основанные на принципе «максимальных усилий».
• Почему бы и нет : Codex — это не узкоспециализированное приложение. Оно управляет открытыми рабочими процессами разработчиков: оболочки, Git, Python, менеджеры пакетов, инструменты сборки и любые другие бинарные файлы, которые агент сочтет необходимыми. На практике это сделало AppContainer неподходящим решением для данной проблемы. Он обеспечивал сильную изоляцию, но для гораздо более узкого класса рабочих нагрузок, чем «позволить агенту работать как разработчик».

Песочница Windows

• Что: Windows Sandbox — это одноразовая, легковесная виртуальная машина от Microsoft. Вы получаете чистый рабочий стол Windows с надежной изоляцией, и все, что вы делаете внутри, исчезает после завершения сессии.
• Почему : Интересен по очевидным причинам — гораздо лучше совместим с произвольным программным обеспечением, чем AppContainer, и с точки зрения безопасности это гораздо более надежный вариант.
• Почему бы и нет : Codex должен взаимодействовать непосредственно с фактическим процессом загрузки, инструментами и средой пользователя, а не внутри отдельного одноразового рабочего стола, который потребует настройки и сопряжения хоста и гостевой системы. Кроме того, у него была фундаментальная проблема с продуктом: Windows Sandbox даже недоступен для версий Windows Home.

Обязательная маркировка целостности (MIC)

• Что : В Windows существует концепция «уровней целостности», таких как низкий, средний и высокий, которые определяют, насколько система доверяет объектам и процессам. Основное правило заключается в том, что процесс с более низким уровнем целостности не может записывать данные в объект с более высоким уровнем целостности, даже если обычный список контроля доступа (ACL) это разрешает. Например, процесс с низким уровнем целостности рассматривается как менее доверенный, поэтому Windows блокирует ему запись в объекты со средним уровнем целостности, если эти объекты явно не перемаркированы для разрешения записи.
• Почему : MIC выглядел элегантно на бумаге — запустить Codex с низким уровнем целостности, переименовать доступные для записи корневые каталоги в каталоги с низким уровнем целостности и позволить Windows запрещать запись во всех остальных местах. Это дало бы нам путь без прав администратора с реальным механизмом операционной системы.
• Почему бы и нет : подобно спискам контроля доступа (ACL), метки целостности изменяют реальную файловую систему хоста, и в данном случае семантическое изменение особенно масштабно. Пометка рабочей области как имеющей низкую целостность означает не просто «Codex может записывать сюда». Это означает, что процессы с низкой целостностью в целом могут записывать туда. На реальной машине разработчика это превращает фактическую загрузку пользователем в приемник с низкой целостностью для хоста, что гораздо рискованнее, чем предоставление тщательно настроенных списков контроля доступа для одной тестовой среды. Даже если инструменты разработчика со средней целостностью продолжат работать, базовая модель доверия рабочей области изменилась таким образом, что её трудно сдержать и ещё труднее оправдать.

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

Первый прототип: «неприподнятая песочница».

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

Ограничение записи файлов

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

SID позволяют нам придать песочнице индивидуальность.

SID, или идентификатор безопасности, — это идентификатор, который Windows связывает с разрешениями . У каждого пользователя есть SID, у групп есть SID, и даже отдельная сессия входа в систему получает свой собственный SID. Например, текущая сессия входа в систему может иметь SID типа S-1-5-5-XY . SID, назначенный локальной группе администраторов, может быть S-1-5-32-544 .

Windows также позволяет создавать синтетические SID, которые не соответствуют реальному пользователю, но могут отображаться в списках контроля доступа (ACL), определяющих, кто может читать/записывать/выполнять определенные файлы или каталоги. Это делает SID полезным инструментом для нашей песочницы: мы можем создавать SID исключительно для использования в песочнице Codex, не вмешиваясь в работу других компонентов на машине.

Токены с ограничением на запись ограничивают возможности Codex по изменению файлов.

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

Для успешной записи необходимо пройти две проверки:

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

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

Используя SID и токены с ограничением на запись, наша песочница без повышенных прав работала следующим образом:

1. В процессе настройки песочницы был создан синтетический SID под названием sandbox-write .
2. Идентификатору SID sandbox-write были предоставлены права на запись, выполнение и удаление .
   1. Текущий рабочий каталог
   2. Любые дополнительные права доступа для записи, настроенные в файле config.toml .
3. В настройках песочницы явно запрещался доступ на запись для того же SID в области, доступные только для чтения внутри областей, доступных для записи, таких как:
   1. /.git
   2. /.codex
   3. /.agents
4. Codex запускал команды, используя токен с ограничением на запись, список ограниченных SID которого включает Everyone , SID текущей авторизованной сессии и синтетический SID для записи в песочнице .

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

Ограничение доступа к сети

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

Без возможности использовать брандмауэр Windows мы ограничили свои возможности контроля. Мы попытались сделать так, чтобы дочерняя среда автоматически закрывалась для сетевых инструментов, которые действительно используют разработчики, чтобы команды Git, установщики пакетов и т. д. завершались с ошибкой в песочнице, и пользователю приходилось бы подтверждать любые операции, обращающиеся к интернету. Идея заключалась в том, чтобы испортить очевидные пути отступления: отправлять трафик с поддержкой прокси на неработающий конечный пункт, заставить транспорт HTTP(S) Git делать то же самое и заставить Git через SSH немедленно завершаться с ошибкой. Вдобавок к этому мы добавили небольшой каталог denybin в PATH и изменили порядок PATHEXT , чтобы заглушки скриптов SSH и SCP разрешались раньше реальных бинарных файлов.

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

• HTTPS_PROXY=http://127.0.0.1:9
• ALL_PROXY=http://127.0.0.1:9
• GIT_HTTPS_PROXY=http://127.0.0.1:9
• NO_PROXY=localhost,127.0.0.1,::1
• GIT_SSH_COMMAND=cmd /c exit 1

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

Невысокий уровень подхода подразумевал определенные компромиссы.

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

• Скорость настройки: Применение списков контроля доступа (ACL) к рабочей области может быть затратным в зависимости от топологии каталога рабочей области.
• След от сервера: Мы применили реальные списки контроля доступа (ACL) к системе разработчика, хотя этот след не является особенно инвазивным, поскольку все примененные ACL относятся к созданному на заказ синтетическому идентификатору безопасности (SID), который используется только в песочнице.
• Сложная в изменении семантика: зависимость от списков контроля доступа (ACL) для ограничений на основе файлов означает, что изменение семантики песочницы является дорогостоящим и сложным процессом. В то время как в macOS мы можем динамически изменять способ генерации файла .sbpl , используемого для настройки Seatbelt, в песочнице Windows для корректировки списков контроля доступа может потребоваться медленная и ресурсоемкая операция.
• Защита сети слабая. Как уже упоминалось, она носила «консультативный» характер, её определённо можно было обойти с помощью некоторых программ, использующих собственный сетевой стек, и она не была разработана для защиты от вредоносного кода.

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

Подавление сети слишком важно.

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

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

• В Windows невозможно сопоставить правило брандмауэра с неосновным идентификатором ограниченного токена. Это означает, что мы не могли бы применить правило брандмауэра к «любому токену, который включает наш синтетический SID в свой список ограниченных SID».
• Хотя мы могли бы создать правило брандмауэра, соответствующее конкретному исполняемому файлу, это позволило бы нам ограничить сетевые возможности только для самого codex.exe . Это не распространялось бы на процессы, которые агент запускает от имени пользователя, например, процессы Git или Python.
• Другие параметры соответствия брандмауэра также были неправильной формы. Правила, ограниченные пользователем, по-прежнему соответствовали реальному пользователю Windows в нерасширенном режиме, а не только ограниченному дочернему процессу. Правила, основанные на пути к программам, были слишком грубыми: они могли блокировать codex.exe или python.exe в целом, но не этот конкретный изолированный вызов python.exe . Правила, основанные на портах или адресах, также были совершенно неправильной политикой. Например, мы не хотели блокировать порт 443; мы хотели блокировать произвольный исходящий доступ для этого конкретного дерева процессов с ограниченным доступом.

Чтобы применить правило брандмауэра специально к нашим изолированным командам, нам нужно было запускать их от имени отдельного субъекта, а не от имени «реального» пользователя. Такой подход привел нас к новому пути, в рамках которого мы ослабили ограничение на «отсутствие повышенных прав».

Перепроектирование: «приподнятая песочница»

Следующая итерация песочницы, которая является нашей текущей реализацией, требует повышенных административных прав во время настройки. Поэтому я называю её «песочницей с повышенными правами». На границе, где Codex запускает команду в системе, песочница с повышенными правами выглядит так же, как и песочница без повышенных прав. Она по-прежнему запускает дочерние процессы под ограниченным токеном — аналогично токену write_restricted с тем же ограниченным списком SID [Everyone, Logon, Synthetic ] — однако субъектом этого токена больше не является фактический пользователь Windows, а один из двух локальных пользователей, созданных самим Codex:

• CodexSandboxOffline (тот, на который нацелены правила брандмауэра)
• CodexSandboxOnline (тот, который не является целью правил брандмауэра)

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

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

Теперь нам необходим первоклассный этап настройки.

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

• При необходимости создайте синтетический SID.
• Примените списки контроля доступа (ACL) для синтетического идентификатора состояния записи в песочнице.

Однако на приподнятой песочнице предстоит сделать гораздо больше.

• Создайте синтетический SID, если он еще не создан.
• Создайте пользователей онлайн- и офлайн-песочницы, если они еще не созданы.
• Сохраните учетные данные вновь созданных пользователей локально и зашифруйте их с помощью API защиты данных Windows (DPAPI) в месте, недоступном для чтения пользователями песочницы.
• Создайте правила брандмауэра, блокирующие весь исходящий сетевой доступ для пользователя CodexSandboxOffline , или, если они уже существуют, проверьте их корректность.

На этапе настройки есть еще один нюанс. Ожидается, что песочница Codex будет иметь доступ на чтение, эквивалентный доступу фактического пользователя Windows. В песочнице без повышенных прав, где основным SID ограниченного токена был пользователь Windows, это было достигнуто. Однако это не происходит автоматически, когда основной пользователь становится новым пользователем CodexSandbox . Многие соответствующие каталоги в Windows предоставляют права на чтение/выполнение «аутентифицированным пользователям». Один из примечательных примеров — каталог профиля пользователя. По умолчанию пользователи Windows не могут читать каталоги профилей других пользователей Windows, поэтому даже простое чтение файлов во многих сценариях завершится неудачей.

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

• C:Users
• C:Windows
• C:Program Files
• C:Program Files (x86)
• C:ProgramData

Поскольку этот список каталогов составлен с учетом наилучших возможностей, а установка списков контроля доступа (ACL) для каждого из них может быть довольно затратной, мы выполняем эту логику асинхронно, чтобы этап настройки песочницы, который блокирует доступ пользователей, не ждал его завершения.

Мы выделили логику установки в отдельный исполняемый файл, отчасти для того, чтобы преодолевать ограничение UAC только при необходимости. Но более глубокая причина была архитектурной: установка в песочнице выполняет принципиально иную задачу, чем codex.exe . Размещение логики установки в песочнице в отдельном исполняемом файле позволило codex.exe оставаться обычным, не требующим повышенных прав; предотвратило раздувание codex.exe механизмом установки, предназначенным только для Windows , на других платформах; отделило длительные процессы установки от жизненного цикла основного процесса; и предоставило нам единое место для обработки различных путей установки, необходимых для песочницы.

Command Runner — это новый исполняемый файл, который фактически выполняет команды пользователя.

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

• Файл codex.exe запускается от имени реального пользователя Windows. Затем, в определенной последовательности, Codex:
  • Вызывает LogonUserW(…) для пользователя песочницы.
  • Вызывает метод CreateRestrictedToken(…) для токена пользователя песочницы.
  • Используя этот ограниченный токен пользователя песочницы, вызывается функция CreateProcessAsUserW(…) для запуска конечного дочернего процесса.

На практике желаемый алгоритм не сработал из-за ограничения привилегий в функции CreateProcessAsUserW(…) . Это означает, что codex.exe мог создать ограниченный токен для пользователя песочницы, но не мог надежно запустить дочерний процесс с этим токеном со стороны реального пользователя. Нам нужен был процесс, который уже работал от имени пользователя песочницы — это позволило бы этапу ограничения и окончательному запуску происходить на стороне пользователя песочницы, а не на стороне реального пользователя.

Это требование привело к созданию codex-command-runner.exe — нового исполняемого файла, единственная задача которого — создать ограниченный токен и запустить запрошенную команду. Вместо того чтобы просить codex.exe выполнять весь процесс самостоятельно (реальный пользователь → пользователь песочницы → ограниченный токен → дочерний процесс), мы разделили этот процесс на две части:

Часть 1

• codex.exe вызывает CreateProcessWithLogonW(…) для запуска codex-command-runner.exe от имени пользователя песочницы, пока без использования ограниченного токена.

Часть 2

• Внутри среды выполнения OpenProcessToken(GetCurrentProcess(), …) открывает собственный токен среды выполнения, который уже принадлежит пользователю песочницы.
• Исполнитель вызывает GetTokenInformation(…) для извлечения SID входа в песочницу, а затем CreateRestrictedToken(…) для создания окончательного ограниченного токена.
• Внутри исполняемого процесса вызывается функция CreateProcessAsUserW(…) с этим ограниченным токеном для запуска реального дочернего процесса.

Полная картина

Альберт Эйнштейн сказал: «Всё должно быть максимально простым, но не проще». В этом духе наш проект адекватно решил каждую из проблем. Финальная архитектура включает в себя четыре слоя, которые мы рассмотрели ранее:

• сам codex.exe
• Файл codex-windows-sandbox-setup.exe используется для выполнения всех действий, связанных с установкой с правами администратора.
• codex-command-runner.exe для выполнения команд с ограниченным доступом к токенам.
• Процесс воспитания ребенка

Когда я только начинал этот проект, у меня не было четкого представления о том, к чему он приведет. Мой подход заключался в том, чтобы начать с внедрения возможностей песочницы на границе между Codex и операционной системой. Этот подход очень похож на то, как реализована песочница Codex в macOS и Linux.

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

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

Баланс между безопасностью и реальной пользой

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

Один из главных уроков этого проекта заключался в том, что Windows не предоставила нам ни одного базового элемента, который бы однозначно соответствовал «безопасному автономному агенту программирования». Мы разработали несколько инструментов и концепций, чтобы создать нечто целостное. Некоторые ранние идеи оказались тупиковыми. Финальный дизайн представлял собой гибрид более ранних прототипов, каждый из которых решал часть проблемы.

Другой урок заключался в том, что безопасность для агента программирования — это совсем другое дело, чем более классическая безопасность приложений. Codex должен работать в реальных рабочих процессах разработчиков. Инженерная работа заключалась в балансе между совместимостью с рабочими нагрузками агентов и реальным обеспечением безопасности. Это противоречие определило компромиссы в окончательном проекте.

Хотите увидеть песочницу Codex в действии? Попробуйте !

Продолжайте читать

Просмотреть все Наша реакция на атаку на цепочку поставок npm от TanStack

Компания, 13 мая 2026 г.

Безопасное использование Codex в OpenAI

Безопасность 8 мая 2026 г.

Масштабирование доверенного доступа для кибербезопасности с помощью GPT-5.5 и GPT-5.5-Cyber

Безопасность 7 мая 2026 г.

Источник: openai.com