Windows-sandbox для Codex: как OpenAI построила безопасную среду агента на Windows

Windows-sandbox для Codex — это не косметическое обновление Windows-клиента. OpenAI решает более жёсткую задачу: как пустить агента для программирования на машину разработчика и не дать ему превратиться в источник утечек, лишних прав и случайных разрушительных действий. По состоянию на 13 мая 2026 года компания уже раскрыла базовые элементы этой схемы в документации Codex для Windows и в отдельном материале о безопасности.

Главный сюжет здесь не в том, что Codex «теперь работает на Windows». Это рынок уже видел. Куда интереснее сам контур исполнения. В официальной документации OpenAI перечисляет три практических режима для Windows: нативный elevated sandbox, нативный unelevated sandbox и запуск через WSL2 с Linux-sandbox. Из этого видно простую вещь: одного встроенного механизма Windows для такого агента оказалось недостаточно. Пришлось собирать границу из нескольких уровней ОС сразу.

Что OpenAI публично раскрыла о Windows-sandbox для Codex

На странице Windows – Codex | OpenAI Developers OpenAI пишет, что в нативном режиме Codex блокирует запись вне рабочей папки и не даёт агенту выходить в сеть без явного разрешения. Для этого компания предлагает три практических варианта запуска:

• elevated — основной нативный sandbox для Windows;
• unelevated — запасной нативный режим, если администраторская настройка недоступна;
• WSL2 — путь через Linux-sandbox для команд, которые и так работают в WSL.

Важен не сам список, а логика этой конструкции. OpenAI не обещает, что любой Windows-ноутбук мгновенно превращается в безопасную среду для агента. Компания честно показывает лестницу компромиссов: сильный нативный режим, более слабый запасной вариант и путь через WSL2.

Почему OpenAI делает ставку на elevated-режим

В той же документации OpenAI прямо называет elevated предпочтительным нативным режимом для Windows. Компания пишет, что он использует dedicated lower-privilege sandbox users, filesystem permission boundaries, firewall rules и local policy changes, которые нужны командам внутри sandbox.

Это, пожалуй, самый содержательный фрагмент всей публикации. OpenAI не продаёт защиту как один «контейнер». Она раскладывает её на несколько отдельных слоёв: низкопривилегированные пользователи, границы файловой системы, сетевые правила и локальные политики. Именно такой набор и нужен, если агент должен запускать команды и менять файлы в проекте, но не получать автоматический доступ ко всей машине.

Отдельно OpenAI отмечает, что оба нативных режима по умолчанию используют private desktop для более жёсткой изоляции интерфейса. Это тоже важная деталь. Речь идёт не только о доступе к файлам. Компания изолирует и окно взаимодействия с рабочим столом, а старое поведение Winsta0\Default оставляет только как режим совместимости.

Что уступает unelevated-режим

Запасной режим OpenAI тоже описывает без лакировки. В документации сказано, что unelevated запускает команды с restricted Windows token, полученным от текущего пользователя, применяет ACL-based filesystem boundaries и использует environment-level offline controls вместо отдельного firewall rule для offline-пользователя.

Ключевая формулировка здесь короткая и честная: it’s weaker than elevated. OpenAI прямо предупреждает, что этот режим слабее и годится скорее как практический запасной вариант, когда полноценная администраторская настройка упирается в локальную или корпоративную политику. Для корпоративных команд это хороший маркер зрелости: компания не маскирует компромисс и не делает вид, что любой нативный запуск одинаково безопасен.

Практический вывод отсюда простой. Если Windows-команда хочет доверять Codex реальные рабочие задачи, нормальной целью должен быть именно elevated. unelevated — это способ не останавливать пилот совсем, но не тот режим, который стоит считать финальным состоянием.

Sandbox без approvals не работает

На странице Agent approvals & security – Codex OpenAI описывает вторую половину этой модели. По умолчанию локальный Codex работает с выключенным сетевым доступом. Sandbox задаёт техническую границу, а approval policy определяет, когда агент должен остановиться и попросить разрешение выйти за неё.

OpenAI формулирует это как двухслойную схему: sandbox mode отвечает за то, что агент технически может сделать, а approval policy — за то, когда он вообще может попытаться это сделать. В режиме workspace-write агент может читать файлы, править код и запускать команды внутри рабочей директории, но запросит подтверждение для действий вне workspace или для команд, которым нужен network access.

Для Toolarium это важное уточнение. Без него легко перепутать локальный sandbox с полностью автономным и безопасным агентом. OpenAI показывает обратную картину: даже сильный Windows-sandbox — это только половина контура. Вторая половина — явные остановки там, где агенту нужен доступ шире, чем ему выдали изначально.

Как это связано с общим контуром безопасности Codex

Отдельный официальный материал Running Codex safely at OpenAI, опубликованный 8 мая 2026 года, переносит тот же принцип на внутреннюю эксплуатацию Codex. OpenAI пишет, что не даёт агенту open-ended outbound access, использует управляемую сетевую политику, правила для команд и агентную телеметрию через OpenTelemetry и compliance-логи.

Важно, что Windows-sandbox в этой схеме не существует сам по себе. Сначала OpenAI ограничивает запись и сетевой доступ локально, затем добавляет policy-слой для approvals и доменов, а сверху оставляет логи, по которым служба безопасности может разбирать не только то, что сделал агент, но и почему он это сделал. Для корпоративного внедрения важна именно эта связка, а не голый факт «агент запускается на Windows».

Это же объясняет, почему новый материал не стоит смешивать с темами вроде защиты аккаунта или общей prompt governance. Большой апрельский релиз Codex объяснял, как OpenAI превращает Codex в рабочую среду для агентного программирования. История с утечкой системного промпта показывает другой класс рисков вокруг инструментов и границ модели. Windows-sandbox решает более приземлённую, но критичную задачу: как ограничить действия агента на локальной машине и в репозитории до того, как он доберётся до более чувствительных систем.

Почему это важно для Windows-команд

Для Mac и Linux идея sandboxed agent уже стала привычной. Для Windows-команд она долго оставалась менее очевидной: слишком много процессов завязано на PowerShell, корпоративные политики, локальные IDE, сетевые ограничения и legacy-настройки. Поэтому сам факт, что OpenAI теперь документирует не один, а несколько поддерживаемых контуров для Windows, важен сам по себе.

Во-первых, это снижает барьер для пилота. Команда может начать с WSL2 или даже с unelevated, если инфраструктура пока не даёт развернуть полноценный sandbox с администраторской настройкой. Во-вторых, документация ясно показывает, куда стоит идти: к нативному elevated режиму с отдельными пользователями, firewall rules и private desktop. В-третьих, сама модель OpenAI помогает разговаривать с безопасниками на одном языке: границы workspace, сетевой доступ, approvals и логирование.

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

Где предел этой архитектуры

OpenAI не обещает полного отсутствия риска. На той же странице про approvals компания отдельно предупреждает, что full access может привести к непреднамеренным разрушительным действиям и потере данных, а живой web search и network access увеличивают риск prompt injection. Это полезный контраст к запусковым текстам, где sandbox иногда подают как магическую защиту от всех проблем сразу.

Здесь стоит помнить и про более широкий контекст автономных агентов. Мы уже разбирали, почему агентам нельзя бездумно отдавать деньги, секреты и чувствительные контуры. Windows-sandbox не отменяет эту проблему. Он лишь делает базовый слой исполнения заметно жёстче: агент не должен автоматически видеть всю файловую систему, свободно ходить в сеть или работать на обычном рабочем столе как полный пользователь.

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

Вывод

По состоянию на 13 мая 2026 года OpenAI уже достаточно подробно раскрыла, как видит безопасный запуск Codex на Windows. Главный вывод простой: рабочему агенту на Windows мало одной функции ОС. Нужна составная инженерная конструкция. Поэтому лучший режим у OpenAI — это не просто sandbox, а elevated контур с отдельными low-privilege users, файловыми границами, firewall rules, private desktop и approval-политикой сверху.

Для Toolarium это хороший индикатор зрелости рынка. Следующий этап конкуренции coding agents будет идти не только по бенчмаркам и качеству diff, но и по тому, насколько убедительно вендор умеет ограничить агента там, где ему действительно есть что сломать.