Песочница Codex в Windows: os error 32 и исправленные сборки

Если в Windows каждая команда Codex, чтение файла или запуск Node REPL падает ещё до старта с helper_unknown_error: setup refresh had errors, а в журнале песочницы рядом с node_repl.exe стоит (os error 32), это ошибка самого Codex, а не вашего проекта и не прав доступа. Помощник настройки песочницы из октябрьских сборок пытался открыть файлы, которые к этому моменту уже запустил сам Codex, и Windows ему отказывала.

По состоянию на 22 октября 2026 года исправление есть для всех компонентов:

• настольное приложение — сборка 26.1007.21434 (build 13901) и новее. Исправление подтвердили несколько пользователей, в журнале изменений OpenAI отдельной строки о нём нет;
• Codex CLI из npm и фоновый сервер (daemon) — версия 0.163.0 и новее. Версии 0.161.0, 0.162.0 и 0.162.1 ошибку ещё содержат.

Обновить нужно всё, что стоит на компьютере, и после этого полностью перезапустить Codex: старый CLI ломает песочницу даже рядом с уже исправленным приложением. Менять режим песочницы, выключать Defender или переписывать права на папки для этого не нужно.

Как узнать ошибку: node_repl.exe и os error 32 в журнале песочницы

Снаружи сбой выглядит по-разному в зависимости от того, где вы работаете с Codex, но всегда одинаково по сути: ни одна команда не успевает запуститься.

• В приложении и CLI: Failed to create unified exec process: helper_unknown_error: setup refresh had errors или exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors.
• Node REPL, Computer Use и встроенный браузер: windows sandbox failed: helper_unknown_error: setup refresh had errors, а затем trusted Node process exited unexpectedly или node_repl kernel exited unexpectedly.
• В приложении может появиться сообщение о незавершённой настройке Windows (в английском интерфейсе — «Windows setup didn't finish» или «Setup stopped»), а повторная попытка не вызывает запрос UAC.

Точный диагноз даёт журнал песочницы: %USERPROFILE%\.codex\.sandbox\sandbox.2026-10-22.log (в имени файла — текущая дата; в документации OpenAI этот же журнал описан как CODEX_HOME/.sandbox/sandbox.log). Фатальная запись выглядит так (отчёт с журналом в #51601):

runtime read/execute validation failed: validate runtime read/execute access on
C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node_repl.exe:
open ACL target for root-only update: The process cannot access the file because
it is being used by another process. (os error 32)
...
top-level error: setup refresh had errors

Вместо node_repl.exe в той же строке может стоять ...\bin\node_modules\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll — это та же ошибка. На русской Windows текст ошибки локализован: «Процесс не может получить доступ к файлу, так как этот файл занят другим процессом».

Что означает ошибка 32 и почему перезагрузка не помогает

Код 32 в Windows — это ERROR_SHARING_VIOLATION, нарушение совместного доступа: файл уже открыт или выполняется, и система не даёт открыть его с запрошенными правами (список системных кодов Microsoft). В виде HRESULT тот же код записывается как 0x80070020.

Причину OpenAI описала в PR #51822 «Avoid sharing violations when repairing Windows runtime ACLs», влитом 7 октября: при проверке прав на файлы среды выполнения помощник открывал запущенные EXE и DLL с доступом MAXIMUM_ALLOWED, и на работающем файле это заканчивалось нарушением совместного доступа. Исправленный помощник запрашивает такой доступ только для папок, а у файлов просит READ_CONTROL | WRITE_DAC и только тогда, когда права действительно нужно поменять.

Неприятная деталь в том, что Codex сам запускает node_repl.exe ещё до первой команды, а DLL держит его же процесс codex-computer-use-swift.exe. Поэтому старый помощник не мог пройти проверку ни разу: после перезапуска приложения или перезагрузки Windows Codex снова поднимает эти процессы, и всё повторяется.

Сбой начался 7 октября 2026 года с обновлением настольного приложения до 26.1002.51308 (build 13417) и пакетов 26.1002.6548.0, 26.1002.7124.0 и 26.1002.52244. В них входил встроенный CLI 0.162.0-alpha.2; журналы предыдущего помощника из 0.160.x чистые (#51601, #52328). Чаще всего ошибка встречается с параметром [windows] sandbox = "elevated".

Строка с ошибкой 32 и «continuing setup» безвредна

В том же журнале часто есть ещё одна запись с ошибкой 32, которая к сбою отношения не имеет:

failed to grant non-inheriting read-attributes ACE on user profile C:\Users\<user>:
open ACL target for root-only update ... (os error 32); continuing setup

Ключевые слова здесь — user profile и continuing setup: настройка продолжается и может закончиться успешной строкой errors=[]. Ориентируйтесь только на ошибку 32 у файлов в runtimes\cua_node\<hash> и на итоговое setup refresh had errors.

Исправленные версии Codex для Windows по компонентам

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

Для CLI всё задокументировано: в примечаниях к релизу 0.163.0 от 15 октября прямо указан #51822. Сотрудник OpenAI в #54325 и #54405 написал, что 0.161.0 и 0.162.1 по-прежнему с ошибкой (поэтому откат CLI не помогал), и попросил обновиться до 0.163.0 или новее, а затем перезапустить Codex вместе с работающим приложением и фоновым сервером. Стабильные 0.162.0 и 0.162.1 исправления не содержат: в их коде проверки прав (codex-rs/windows-sandbox-rs/src/acl.rs) его нет, а в 0.163.0 и в 0.162.0-alpha.17.2 — есть.

С приложением ситуация менее формальная. Журнал изменений OpenAI для 26.1007 эту правку не упоминает, а запись к 26.1002 «Fixed Windows sandbox refresh failures after app updates» относится к другому сбою: ошибку 32 на более поздних пакетах 26.1002 продолжали получать. Номер 26.1007.21434 — это сборка, на которой пользователи один за другим сообщили, что ошибка ушла без каких-либо дополнительных действий (подтверждения в #51601): обычные команды завершаются с кодом 0, Node REPL и Computer Use запускаются, а у пользователя ChatGPT Business с правилами запрета чтения в журнале появилось errors=[]. В отчётах встречаются и более новые сборки: 26.1007.9446.0, 26.1007.71326, 26.1013.x.

Чего OpenAI не сообщала: с какой именно сборки приложения исправление вошло в каждый канал обновлений и как обстоят дела на непроизводственных каналах. Для расширения VS Code отдельного номера исправленной версии тоже нет ни в официальных, ни в пользовательских источниках; обновите его и проверьте результат командой из следующего раздела.

Как устранить os error 32: обновить, перезапустить, проверить

1. Обновите настольное приложение до 26.1007.21434 или новее и посмотрите номер в окне About. Пользователям, у которых ошибка ушла, хватило установить обновление и дать приложению перезапуститься; перезагружать Windows не понадобилось.

2. Обновите npm CLI, если он у вас стоит, даже если вы им почти не пользуетесь:

   powershell

   npm install -g @openai/codex@latest
   codex --version

   Нужна версия 0.163.0 или новее.

3. Полностью перезапустите Codex. Закройте приложение и терминалы с Codex, затем в диспетчере задач убедитесь, что не осталось процессов codex.exe, node_repl.exe и других процессов из %LOCALAPPDATA%\OpenAI\Codex\. Если вы пользуетесь фоновым сервером, перезапустите и его: старый процесс продолжает работать со старым помощником.

4. Проверьте песочницу без обращения к модели. Удобнее всего — при открытом приложении: тогда проверка заодно показывает, что CLI и приложение уживаются вместе.

   powershell

   codex sandbox cmd /c "cd && echo SANDBOX-OK"
   $LASTEXITCODE

   Форма команды из документации OpenAI (нужен CLI 0.162.0 или новее): codex sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo SANDBOX_OK.

5. Сверьтесь с журналом. Успех — это напечатанный маркер, код выхода 0 и свежая строка вида setup refresh: processed N write roots ...; errors=[] в сегодняшнем sandbox.<дата>.log. В приложении достаточно попросить Codex в новом чате выполнить Get-Location.

Если проверка прошла, а режим песочницы вы на время меняли на unelevated, верните elevated (подробнее — в разделе про временный обход).

Обновили, а setup refresh had errors осталась

После обновления ошибка остаётся почти всегда по одной из трёх причин: где-то продолжает работать неисправленный компонент.

Старый npm CLI рядом с исправленным приложением

Среда выполнения cua_node лежит в %LOCALAPPDATA%\OpenAI\Codex\runtimes\ и общая для приложения и CLI. CLI при своей настройке песочницы тоже проверяет права на её файлы, поэтому npm CLI 0.162.1 падает с той же ошибкой 32, пока рядом работает приложение — даже уже исправленное 26.1007.9446.0. Как только приложение полностью закрыто, та же команда CLI проходит (отчёт от 15 октября). Отдельный CODEX_HOME от этого не спасает: среда выполнения находится не в нём.

Сюда же относятся расширение VS Code и сторонние инструменты, которые вызывают ваш CLI через codex app-server. Решение одно — CLI 0.163.0 или новее.

Сеанс codex app-server держит node_repl.exe сам

В неинтерактивном сеансе codex app-server файл node_repl.exe занимает собственный процесс этого сеанса, поэтому закрытие настольного приложения здесь ничего не даёт (#54138). Коварство в том, что ответ модели может выглядеть нормально, хотя ни одна команда на самом деле не выполнилась. Если у вас такой сценарий, проверьте версию именно того CLI, который запускает сеанс.

Устаревший CODEX_CLI_PATH в config.toml и .mcp.json

Подробный пользовательский разбор в #54635 описывает случай, когда CLI 0.163.0 уже стоит, а Computer Use и браузер всё равно падают. Переменная CODEX_CLI_PATH, по которой запускаются node_repl и Computer Use, осталась привязанной к старой сборке %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe с версией 0.162.0-alpha.2. Записана она в двух местах:

• %USERPROFILE%\.codex\config.toml, раздел [mcp_servers.node_repl.env];
• %USERPROFILE%\.codex\plugins\cache\openai-bundled\unified-computer-use\<версия>\.mcp.json.

Как проверить: в сегодняшнем журнале песочницы найдите строки setup refresh: spawning ..., после которых идёт ошибка 32. Если путь в них ведёт в OpenAI\Codex\bin\<hash>\codex-windows-sandbox-setup.exe, выполните --version у codex.exe из той же папки. Старая версия (например, 0.162.0-alpha.2) при уже обновлённом приложении и CLI — признак этой проблемы.

Что помогло автору отчёта: сделать резервные копии обоих файлов, указать в CODEX_CLI_PATH путь к самому новому codex.exe (у него это %USERPROFILE%\.codex\packages\app-server-daemon\releases\<версия>\bin\codex.exe, проверить через --version) и полностью перезапустить Codex. Переустановка, по его словам, не помогает, потому что значение не перезаписывается. Учитывайте ограничения: это одно сообщение без ответа сотрудников OpenAI, раскладка папок на вашем компьютере может отличаться, а следующее обновление может вернуть старый путь. Исправит ли OpenAI запись этого пути в будущих обновлениях, не объявлено, поэтому после обновлений стоит проверять его снова. Где находится config.toml и что в нём настраивается, описано в статье «Песочница Codex и config.toml: границы, подтверждения и сеть».

Что не помогает при ошибке 32 и чего делать не стоит

По отчётам пользователей и ответу сотрудника OpenAI, на неисправленных сборках не работает:

• перезапуск приложения, перезагрузка Windows и новый чат;
• переустановка — старый путь в CODEX_CLI_PATH сохраняется;
• завершение node_repl.exe в диспетчере задач: помогает до запуска следующего ядра, после чего ошибка возвращается, а работающий сеанс теряет node_repl до перезапуска;
• явное добавление прав чтения и выполнения на node_repl.exe — права у группы песочницы и так есть, проблема не в них;
• откат npm CLI до 0.161.0 — эта версия тоже с ошибкой.

Откат самого приложения на 26.930.7945.0 — непроверенный совет: подробных отчётов с журналами о нём нет, а исправленная сборка уже вышла.

Не стоит «лечить» ошибку 32 постоянным полным доступом, отключением Defender или сменой владельца и ACL у папок Codex. Файл занимает сам Codex, и никакие права это не меняют, а такие шаги снимают защиту, ради которой песочница существует. Советы с icacls и сменой владельца относятся к ошибке 5 (отказ в доступе), а не к 32.

Если обновиться нельзя: unelevated или MXC и их цена

Режим unelevated — только на время

Если обновление пока недоступно, у части пользователей команды вернулись после переключения на запасной режим unelevated в %USERPROFILE%\.codex\config.toml (сначала сделайте копию файла):

[windows]
sandbox = "unelevated"

Цена описана в документации OpenAI о песочнице Windows: unelevated — запасной (legacy) режим на случай, когда настройка elevated недоступна и это разрешает политика организации. Команды выполняются с ограниченным токеном текущего пользователя, сетевая изоляция слабее, а запрещённые для чтения пути не поддерживаются. На управляемых компьютерах администратор может запретить этот режим через allowed_sandbox_implementations.

Результаты при этом разные: у одних пользователей всё заработало сразу, у другого unelevated упал с cannot enforce split writable root sets, третьему понадобился ещё sandbox_mode = "workspace-write". Это обход, а не исправление: после обновления верните sandbox = "elevated".

MXC вместо elevated на Windows 11

В той же документации рекомендуемым режимом на совместимых устройствах назван mxc: он не требует настройки с правами администратора, отдельных учётных записей и правил брандмауэра, а elevated теперь считается предпочтительным запасным режимом. Нужна Windows 11 24H2 со сборкой 26100.9278 или 25H2 со сборкой 26200.9278 и новее, причём Microsoft ещё раскатывает нужные возможности. Настольное приложение для личных аккаунтов само выбирает MXC, если устройство его поддерживает; в CLI это включается так:

[features]
prefer_mxc = true

Проверить MXC на одной команде, не меняя настроек (CLI 0.162.0 и новее):

codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
$LASTEXITCODE

Ожидается MXC_OK и код 0. Если вместо этого появляется CreateProcessSecurityEnvironment failed (HRESULT = 0x80070020), это отдельная ошибка на пути MXC: 0x80070020 — тот же код 32, но исправление из 0.163.0 её не касается. По состоянию на 22 октября #55230 открыта без ответа сотрудников; её видят в приложении 26.1013.x на Windows 11 25H2, а у одного из пользователей CLI без MXC при этом работал.

Другие ошибки песочницы Codex в Windows: error 5, 1385, 740

Не каждая ошибка песочницы — это ошибка 32. Если в журнале нет нарушения совместного доступа на файлах cua_node, обновление до 26.1007.21434 и 0.163.0 вашу проблему, скорее всего, не решит.

Если не завершилась сама настройка elevated, документация советует повторить её и подтвердить запрос администратора, а на компьютерах без прав администратора — попросить IT выполнить подготовку командой codex sandbox setup --elevated --user 'DOMAIN\alice' --codex-home 'C:\Users\alice\.codex' (с вашими учётной записью и путём). Если же приложение не запускается совсем, а сообщения упоминают codex app-server, смотрите разбор «Failed to start codex app-server в Windows: ошибки и что делать».

Ошибка 32 на исправленных версиях: что отправить в OpenAI

Если приложение уже 26.1007.21434 или новее, CLI и фоновый сервер — 0.163.0 или новее, CODEX_CLI_PATH указывает на свежую сборку, а ошибка 32 на файлах cua_node всё равно появляется, сотрудник OpenAI просит прислать (#54325):

• свежий журнал песочницы из %USERPROFILE%\.codex\.sandbox\ с записью о сбое;
• версии CLI (codex --version), фонового сервера и приложения (окно About);
• используемый режим песочницы: elevated, unelevated или mxc;
• номер сборки Windows (winver).

Пути с именем пользователя в журнале можно заменить условным именем, например user. Папку %USERPROFILE%\.codex\.sandbox-secrets\ не отправляйте никому: документация OpenAI прямо это запрещает.