Песочница Codex в Windows: synthetic SID, два локальных пользователя и firewall
К сентябрю 2025 года у Codex для Windows не было встроенной песочницы, и типичный поток упирался в две крайности: одобрять почти каждую команду агента или включить Full Access без надзора. Codex по умолчанию действует от имени реального пользователя — от запуска тестов до правок в workspace — поэтому политику «широкое чтение, запись только в каталоге проекта и без сети, пока не разрешишь» пришлось закрепить на уровне ОС, а не в тексте подсказок.
Почему не взяли готовые коробки
- AppContainer — сильная изоляция, но под приложения с заранее известным набором прав; агенту нужны shell, Git, Python, пакетные менеджеры и произвольные бинарники.
- Windows Sandbox — одноразовая VM с жёсткой границей, но Codex должен работать с реальным checkout и инструментами хоста, плюс режим недоступен на Windows Home.
- Mandatory Integrity Control — низкий уровень целостности для процесса и переразметка workspace превращает каталог в low-integrity sink для всего хоста, а не для одного агента.
От прототипа без elevation до брандмауэра
Первый рабочий вариант оставался без админских промптов: synthetic SID sandbox-write и write-restricted токен резали запись до текущего каталога и путей из writable_roots в config.toml, с явными запретами на запись в .git, .codex и .agents. Сеть глушили через «ядовитые» прокси вроде HTTPS_PROXY=http://127.0.0.1:9, отключение Git SSH и заглушки в PATH — но обходился любой код с собственным стеком сокетов.
Чтобы привязать правило Windows Firewall к дереву процессов агента, финальная схема один раз поднимается с правами администратора: создаются локальные пользователи CodexSandboxOffline (под него вешается блок исходящего трафика) и CodexSandboxOnline, учётные данные шифруются через DPAPI, а команды гоняет отдельный бинарник codex-command-runner.exe — иначе граница CreateProcessAsUserW не даёт надёжно стартовать дочерний процесс с нужным restricted-токеном с стороны «настоящего» пользователя.
Набор из codex.exe, codex-windows-sandbox-setup.exe, codex-command-runner.exe и дочернего процесса выглядит громоздко, но каждый слой закрывал конкретный провал: от дорогих ACL на всём дереве workspace до невозможности сматчить firewall на synthetic SID в restricted-токене.
Смысл для продакшн-агента тот же, что и на macOS или Linux: реальное принуждение к политике, а не обещание модели. Только в Windows путь оказался длиннее — вплоть до отдельных локальных учёток под сетевой контур.
Источник: Building a safe, effective sandbox to enable Codex on Windows.