CreateProcess: Rejected("Failed to create unified exec process: helper_unknown_error: setup refresh had errors")

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #38039
• #37049

Powered by Codex Action

Thanks. The suggested duplicate CLI issues do not match my setup:

• This is Codex Desktop App, not standalone Codex CLI.
• where.exe codex returns no result; Codex CLI is not installed.
• %LOCALAPPDATA%\Programs\OpenAI\Codex does not exist.
• The issue persists after reinstalling the Codex Desktop App.

The failure is reproducible in the Desktop App with any command (Get-Location) before PowerShell starts:
helper_unknown_error: setup refresh had errors.

Could this be the same helper-resource discovery issue in the Desktop App sandbox rather than the standalone CLI launcher?

Update: project ownership and sandbox state were checked.

Workspace owners are correct:
D:\Projects -> PC-ALEKSANDR\dorok
D:\Projects\React -> PC-ALEKSANDR\dorok
D:\Projects\React\BezVmyatin74 -> PC-ALEKSANDR\dorok

The sandbox setup itself reports success:
setup refresh: processed 1 write roots (read roots delegated); errors=[]
codex-windows-sandbox-setup.exe] setup binary completed

The repeated concrete failure in the sandbox log is:

hide users: failed to hide current user profile dir (C:\Users\Default):
SetFileAttributesW failed for C:\Users\Default: 5 (Access is denied.)

The app then still reports the generic:
helper_unknown_error: setup refresh had errors

Codex resolves and reuses the packaged command runner successfully, so this does not appear to be a missing CLI resource or workspace ACL issue. Please investigate why the Windows sandbox tries to change attributes on C:\Users\Default and whether that failure is causing the unified exec process to fail.

I can reproduce this on Codex Desktop for Windows as of 2026-08-16 (JST).

Observed errors:

CreateProcess: Rejected("Failed to create unified exec process: helper_unknown_error: setup refresh had errors")
windows sandbox failed: helper_unknown_error: setup refresh had errors

Impact:

• Minimal PowerShell/file-read diagnostics fail before the shell starts.
• The Node REPL kernel also exits immediately with the same Windows sandbox/setup refresh error.
• apply_patch failed in another Codex task with the same setup refresh error.
• The failure occurs across multiple Codex tasks, so it is not isolated to one prompt or project operation.

Troubleshooting already performed:

• Rebooted Windows.
• Used Windows Settings > Apps > Codex/ChatGPT > Repair.
• Retried after repair; the issue persists.
• Normal Windows use and other applications continue to work.
• No third-party model provider/OpenCodex installation or configuration change was performed before this failure.

A possibly separate symptom started around 2026-08-15 JST: the Codex desktop app has occasionally closed unexpectedly while receiving/processing a large number of task/delegation updates. I cannot confirm that the crash and the setup-refresh failure share the same root cause.

Because all local diagnostic execution is blocked by the same error, I cannot currently collect the app version or run deeper local checks from Codex. Please advise which application logs or Windows diagnostics would be most useful and whether there is a supported recovery procedure for the sandbox setup-refresh state.

Update: I was able to resolve the issue on my system.

The problem was caused by incorrectly configured Windows user environment variables for temporary files:

• TEMP
• TMP

Both variables must point to an existing directory that the current Windows user can write to. In my case, I corrected both values to:

C:\Users\<username>\AppData\Local\Temp

Steps that fixed the issue:

1. Open System Properties → Advanced → Environment Variables.
2. Find the user variables TEMP and TMP.
3. Set both variables to an existing writable temporary directory.
4. Verify that the directory exists and that the current user has permission to write to it.
5. Fully restart Codex.
6. If Codex still uses the previous environment values, restart Windows.

After correcting both variables and restarting Windows, the Codex sandbox started working normally again. Terminal commands, file access, and apply_patch also began working without the helper_unknown_error: setup refresh had errors failure.

The Codex dependency diagnostics had previously reported that everything was fine, so checking TEMP and TMP may be useful when the dependency check passes but the Windows sandbox still fails.

This may not be the cause in every case, but I hope it helps other Windows users experiencing the same issue.

This comment was drafted with assistance from OpenAI's ChatGPT.

По состоянию на 16 августа 2026 года (по японскому стандартному времени) я могу воспроизвести эту проблему на Codex Desktop для Windows. Наблюдаемые ошибки: `` CreateProcess: Rejected("Failed to create unified exec process: helper_unknown_error: setup refresh had errors") windows sandbox failed: helper_unknown_error: setup refresh had errors ` Воздействие: * Минимальная диагностика PowerShell/чтения файлов завершается сбоем до запуска оболочки. * Ядро Node REPL также сразу завершает работу с той же ошибкой обновления песочницы/настройки Windows. * apply_patch` Не удалось выполнить еще одну задачу Codex с той же ошибкой при обновлении настроек. Сбой происходит в нескольких задачах Codex, поэтому он не связан с какой-то одной командой или операцией в проекте. Устранение неполадок уже выполнено: Перезагрузил Windows. Использовал Настройки Windows> Приложения> Codex / ChatGPT > Восстановить. После ремонта проблема не исчезла. Обычное использование Windows и других приложений продолжается. Перед сбоем не выполнялась установка стороннего поставщика моделей/OpenCodex или изменение конфигурации. Возможно, отдельный симптом проявился примерно 15 августа 2026 года по японскому стандартному времени: настольное приложение Codex иногда неожиданно закрывалось при получении/обработке большого количества обновлений задач/делегирования. Я не могу утверждать, что сбой и ошибка при обновлении настроек вызваны одной и той же причиной. Поскольку выполнение всех локальных диагностических процедур блокируется одной и той же ошибкой, я не могу в настоящее время узнать версию приложения или выполнить более глубокие локальные проверки с помощью Codex. Пожалуйста, подскажите, какие журналы приложений или средства диагностики Windows были бы наиболее полезны и существует ли поддерживаемая процедура восстановления состояния после обновления настроек песочницы.

I can reproduce this on Codex Desktop for Windows as of 2026-08-20.

Environment

• Codex Desktop: OpenAI.Codex 26.818.2441.0
• OS: Windows 11 Pro, version 10.0.26200, build 26200
• Local NTFS workspace (not WSL, UNC, cloud-mounted, or removable storage)
• This is recurring; it is not the first occurrence on this machine.

Minimal reproduction

1. Open a local workspace in Codex Desktop.
2. Run a minimal command such as Get-Location.
3. The command fails before PowerShell starts:

CreateProcess: Rejected("Failed to create unified exec process:
helper_unknown_error: setup refresh had errors")

1. Run a minimal browser bridge check:

nodeRepl.write("ready")

1. The kernel exits immediately:

node_repl kernel exited unexpectedly
windows sandbox failed: helper_unknown_error: setup refresh had errors
reason: stdout_eof

1. Resetting the browser/JS kernel and retrying produces the same result.

Impact

• Ordinary sandboxed shell commands cannot start, including read-only commands.
• Browser/Edge control cannot initialize, so authenticated browser sessions cannot be automated.
• This blocks both workspace operations and browser-based tasks.
• The same PowerShell diagnostics succeed when explicitly approved to run outside the sandbox, suggesting that PowerShell and the target commands are valid and that the failure is isolated to sandbox setup/refresh.

TEMP/TMP check

The workaround mentioned above does not appear to apply here:

• User TEMP is configured and points to an existing directory.
• User TMP is configured and points to an existing directory.
• Both variables point to the same directory.

Expected behavior: sandbox setup refresh should succeed, or the error should surface the concrete failing ACL/path/resource instead of only returning helper_unknown_error. Browser initialization should not be prevented by a failed or stale workspace sandbox refresh.

I can reproduce the same Windows sandbox setup/refresh failure described in this issue.

Environment:

• Codex Desktop: OpenAI.Codex 26.818.31338
• Subscription: Plus
• Platform: Windows Windows 11 Pro, 25H2, 26200.9168
• Workspace: Local NTFS workspace, not WSL, UNC, cloud-mounted, or removable storage
• Workspace runtime dependency: 26.819.11345

The issue started after the August 20 update.

Minimal reproduction:

1. In restricted/workspace-write mode, run Get-Location.
2. It fails before PowerShell starts with:

CreateProcess: Rejected("Failed to create unified exec process: helper_unknown_error: setup refresh had errors")

1. Run nodeRepl.write("ready"). The trusted Node process exits unexpectedly.
2. Reset the JS kernel and retry; it fails again.
3. The same Get-Location command succeeds when sandbox restrictions are disabled.
4. A normal PowerShell outside Codex can create and delete a file in %TEMP%.

The failure reproduces across projects and tasks. This strongly suggests that the problem is isolated to the Windows sandbox setup/refresh path, rather than the workspace, PowerShell, or TEMP/TMP permissions.

This appears to be the same issue and may provide an additional independent reproduction for triage.

Independent reproduction from Codex Desktop on Windows, with a more specific lower-level log signal.

Environment

• Codex Desktop: OpenAI.Codex 26.818.4152.0
• Command runner in sandbox log: 0.149.0-alpha.4.1
• Windows 11 Pro: 10.0.26200, build 26200
• Native Windows sandbox: elevated
• Local workspace on D: (not WSL or UNC)

Reproduction and impact

The problem first appeared while multiple Codex tasks were active. That timing is only a correlation; I cannot prove concurrency is the trigger.

1. In workspace-write/restricted mode, run a minimal command such as Get-Location.
2. It fails before PowerShell starts:

CreateProcess: Rejected("Failed to create unified exec process: helper_unknown_error: setup refresh had errors")

1. apply_patch fails with the same setup-refresh error.
2. The same read-only PowerShell command succeeds when explicitly approved outside the sandbox.
3. Fully restarting Codex Desktop does not recover the sandbox.

Lower-level evidence

The latest sandbox log repeatedly reports that setup itself completed successfully:

setup refresh: processed 4 write roots (read roots delegated); errors=[]
setup binary completed

Immediately afterward, the command runner repeatedly logs:

hide users: failed to hide current user profile dir (C:\Users\Default):
SetFileAttributesW failed for C:\Users\Default: 5 (Access is denied.)

Additional checks:

• %USERPROFILE%\.codex\.sandbox\deny_read_acl_state.json exists, is valid JSON, and is 22 bytes; this is not the NUL-filled/corrupt-state case.
• User TEMP and TMP both exist and point to the same directory, so the TEMP/TMP workaround does not apply.
• Git and the workspace remain readable through explicitly approved execution.

Expected behavior: a failure to change attributes on C:\Users\Default should either be handled without preventing all sandboxed processes from starting, or the app should surface this concrete failing operation instead of the generic setup refresh had errors message.

I can independently reproduce this Windows sandbox setup/refresh failure in Codex Desktop.

Notable same-session transition

The workspace was initially functional.

At approximately 22:20, Codex successfully created pomodoro-timer.html in a Google Drive-mounted workspace:

G:\我的雲端硬碟\codex

Codex reported a +76 -0 file change and opened the file in the system's default Chrome browser. I independently confirmed that the file existed and rendered correctly as a working Pomodoro timer.

Approximately one to two minutes later, in the same Codex session and the same workspace, Codex could no longer:

• enumerate the workspace directory;
• re-read the HTML file it had just created;
• read existing .md, .json, .py, or .html files;
• update the existing HTML file;
• run Get-Location or Get-ChildItem;
• initialize controlled browser automation.

The recurring errors were:

helper_unknown_error: setup refresh had errors

and:

windows sandbox failed: helper_unknown_error: setup refresh had errors

The initial file creation and browser launch succeeded, but Codex subsequently lost the ability to inspect, verify, or modify the file it had just created. This suggests that a previously working workspace/sandbox state can become unusable during an active session, rather than the workspace simply being inaccessible from the beginning.

Additional isolation tests

• Restarting the app and creating new tasks did not recover the sandbox.
• A local C: test directory also encountered the same terminal/setup-refresh failure, so the Google Drive-mounted workspace does not appear to be the sole cause.
• Normal PowerShell outside Codex works correctly.
• In a separate OneDrive-hosted project, git status and git log -1 --oneline both succeed, confirming that the normal Windows terminal and Git installation are functional.
• The failure is not related to a particular file format; Codex is blocked before it can access the file contents.

I am not claiming a confirmed ACL or TEMP/TMP root cause because I do not currently have the lower-level sandbox log. The directly observed behavior is that Codex successfully wrote and launched a file, then lost workspace, terminal, existing-file, and browser-control access in the same session.

Please provide either a supported way to reset the Windows sandbox/setup-refresh state or clear instructions for collecting the relevant diagnostic logs.

Additional environment note

The Codex CLI is not installed or available on PATH on this machine. Running codex --version in normal PowerShell returns CommandNotFoundException. This report concerns the Codex Desktop App and its bundled Windows sandbox, not the standalone Codex CLI.

Persistence and TEMP/TMP verification update

The failure first occurred on Friday and was reproduced again on Sunday, so it is not limited to a short-lived failure in one app session.

Before the Sunday retest, both ChatGPT and ChatGPT Classic were fully terminated through Windows Task Manager and ChatGPT was reopened. The normal Codex sandbox still failed before PowerShell started when attempting Get-Location, workspace enumeration, and reading the first five lines of pomodoro-timer.html.

The suggested TEMP/TMP workaround was also tested:

• User-level TEMP and TMP both resolve to C:\Users\user\AppData\Local\Temp.
• Both Test-Path $env:TEMP and Test-Path $env:TMP return True.
• Normal PowerShell successfully created, read, and deleted a test file in that directory.

Therefore, the temporary-directory path and normal user write access are functioning, and that workaround does not resolve this case.

One explicitly approved elevated read was able to access Codex's built-in instructions. However, this does not indicate recovery of the normal sandbox: ordinary workspace reads, file operations, and terminal execution remain blocked by helper_unknown_error: setup refresh had errors.

Independent aggregate from Codex Desktop 26.818.41509 / bundled command runner 0.149.0-alpha.4.1 on Windows:

• The same generic setup-refresh error affected minimal shell reads and apply_patch before the requested operation ran.
• In one task, 21 tool calls failed under the same unchanged setup-refresh state while the agent tried minimal commands and equivalent execution routes.
• Equivalent commands worked only when executed outside the sandbox.

This suggests a token-amplification failure mode in addition to the sandbox bug. Please cache a terminal setup-refresh failure at the host/session level, prevent equivalent tool/helper retries until environment state changes, and return a structured underlying cause plus supported recovery action. That would keep the model from spending further turns rediscovering that syntax and shell changes cannot repair sandbox setup.

I can reproduce the same failure in Codex Desktop on Windows, including in a Google Drive-mounted workspace:

G:\我的雲端硬碟\codex

Failure

PowerShell, cmd, and rg fail before the command starts:

Failed to create unified exec process:
helper_unknown_error: setup refresh had errors

I also saw:

windows sandbox failed: helper_unknown_error: setup refresh had errors

This affects even minimal commands such as Get-Location and Get-ChildItem, so the agent cannot enumerate a directory, read existing files, or run diagnostics.

File-operation behavior

There was an inconsistent but relevant behavior:

• The first apply_patch creating a new test file (AGENTS-copy.md) succeeded.
• After it existed, reading or updating existing files failed.
• Affected file types included .md, .json, .py, and .html.

So this is not simply a Markdown/HTML parsing problem; it appears to block the unified-exec/sandbox path that Codex needs to inspect and modify existing workspace content.

Comparison checks

• Normal Windows PowerShell outside Codex works.
• In a separate OneDrive project, git status and git log -1 --oneline both completed successfully outside Codex.
• Small controlled read/write checks to OneDrive and the Google Drive-mounted path were successful when run through a separately approved system-level route; the Google Drive remote copy could also be read.
• Another Codex task previously completed a small OneDrive read/write test in its ordinary sandbox.

That makes this look intermittent or task/workspace-initialization-specific inside Codex Desktop, rather than a general inability to use cloud-mounted folders or a problem with the project files.

No local project files were modified for this report.

Additional comparison (2026-08-26, Asia/Taipei):

In a separate new Codex Desktop task with workspace C:\Users\user\Documents\Codex, the minimal PowerShell command Get-Location succeeded and returned that directory. No helper_unknown_error: setup refresh had errors occurred in that task.

This does not prove that Google Drive is the root cause of the earlier failure at G:\我的雲端硬碟\codex. It does show that the failure is not a continuously broken, global Windows sandbox state: behavior can differ between tasks/workspaces. The earlier Google Drive task still failed before command execution for PowerShell, cmd, and rg, so it remained unusable for reliable workspace reads/edits at that time.

No local project files were modified for this comparison.