Windows sandbox provisioning fails on stale CUA dependency-cache paths over 260 characters

Summary

After updating Codex Desktop for Windows, every sandboxed command and computer-use call failed before process launch with:

helper_unknown_error: setup refresh had errors

The failure was traced to the Windows sandbox helper validating stale CUA dependency-cache directories whose paths exceed the legacy Win32 path limit. Moving only those unused stale caches out of the runtime tree immediately restored sandbox setup, shell execution, and computer use.

Environment

Codex Desktop: 26.911.7940.0
Codex CLI: 0.155.0-alpha.2.6
OS: Windows 11 Professional, 10.0.26200, x64
Sandbox backend: elevated Windows sandbox
First recorded failure: 2026-09-17T11:33:27Z

Observed behavior

All sandboxed commands failed before launching a process.
Computer-use calls also failed.
codex doctor reported: elevated Windows sandbox provisioning recorded a structured failure with helper_unknown_error.
App restart, full reboot, Windows app Repair, and app reinstall did not resolve it.

Root-cause evidence

The sandbox log reported runtime read/execute validation failure on a stale generated path under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\f24ab376120677c2\bin\node_modules\@oai\sky\dist\js-dependency-cache\shared-v1\applied-bk-agent-openai-js\pnpm-store\v11\links\@rollup\plugin-typescript\12.1.2\a522fe9000e9cb07598cb89328c5f87afda445b7562f1579b3d4e1f77197a142

Evidence collected locally:

Failing path length: 293 characters.
Longest affected cache directory: 312 characters.
The directory existed.
The sandbox group already had Read & Execute permission.
Direct CreateFileW with the normal path failed with Win32 error 3.
The same path with a \\?\ extended-length prefix succeeded.
The signed helper executable's embedded manifest did not declare longPathAware.
Two stale runtime caches were affected; the active runtime itself was not.

Reversible workaround that restored operation

I moved only the unused stale js-dependency-cache directories outside %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node into a backup directory. No ACL, Defender, sandbox-policy, or registry changes were made.

Immediately afterward:

sandbox setup refresh completed with errors=[];
normal commands launched again;
computer use worked again;
setup_error.json was absent;
the sandbox checks in codex doctor passed.

The backup remains available for engineering reproduction if requested.

Expected behavior

The Windows helper should either:

use extended-length Windows paths when validating runtime trees; or
avoid recursively validating generated dependency caches in stale, inactive runtimes.

A single stale cache path should not abort sandbox provisioning for every command and computer-use call.

Additional notes

A repository search found multiple reports of the generic helper_unknown_error: setup refresh had errors, but no issue matching the exact js-dependency-cache / CreateFileW long-path evidence. Sanitized logs and a reproducible diagnostic script can be provided if maintainers need them.

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

Browser control crashes during initialization — Windows #45057

Powered by Codex Action

chore: pin @openai/codex to "0.154.0"

I reproduced this on Codex Desktop for Windows.

Symptoms:

Every normal sandboxed command failed before process launch with:
helper_unknown_error: setup refresh had errors
This affected even Get-Location and also reproduced when trying via cmd.exe.
VS Code Codex on the same machine/workspace continued to work normally.

The Desktop sandbox log consistently showed:

runtime read/execute validation failed:
validate runtime read/execute access on
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\415ffebf3d576e9b
bin\node_modules@oai\sky\dist\js-dependency-cache\shared-v1
applied-bk-agent-openai-js\pnpm-store\v11\links@rollup
plugin-typescript\12.1.2<hash>:
CreateFileW failed

followed by:

setup refresh completed with errors
setup error: setup refresh had errors

A reversible workaround fixed it immediately:
I closed Codex and moved only the js-dependency-cache directory outside
the cua_node runtime directory. After restarting Codex,
Get-Location and normal project file reads worked again.

Additional observation:
The VS Code extension used its own sandbox helper/runtime and reported
errors=[]; the failure only occurred with the Codex Desktop runtime
under %LOCALAPPDATA%\OpenAI\Codex.

This appears consistent with the long-path / stale CUA dependency-cache
failure described in this issue.

I’m encountering a closely matching failure in the Windows desktop app.

Feedback ID: 01a0dda7-530b-76e2-becd-89bbd4270e05

Even Write-Output 'CODEX_EXEC_OK' fails before PowerShell starts with helper_unknown_error: setup refresh had errors.

The sandbox log reports runtime read/execute validation failed and CreateFileW failed under the bundled CUA runtime’s js-dependency-cache, ending in @rollup/plugin-typescript/12.1.2/<hash>.

The directory exists, and its inherited ACL grants CodexSandboxUsers read/execute access. Setting LongPathsEnabled to 1 and fully restarting the app did not resolve the failure.

The helper log does not include the underlying Win32 error number. I have not established whether the affected cache is inactive or safe to relocate. Please advise on a supported repair that preserves sandbox protections and existing data.

I reproduced this on Codex Desktop 26.924.22138 (prod), Windows build 26200, with the elevated sandbox. An existing 283-character directory in an inactive cua_node runtime caused runtime read/execute validation failed / CreateFileW failed. Direct CreateFileW returned error 3 for the ordinary path and succeeded with the extended-length prefix; the helper manifest has no longPathAware declaration. Before recovery, read-only sandbox commands failed in all seven registered local workspaces, and computer use could not start. I moved only the stale js-dependency-cache directory out of the runtime tree to a short backup path; no cache was deleted and no registry or sandbox setting was changed. Afterward, read-only commands succeeded in all seven workspaces, computer use initialized, and setup refresh logged errors=[]. The backup is retained. This restores operation but does not prevent recurrence if the runtime creates another path over the legacy limit.

English

Confirming this issue still occurs on Codex Desktop 26.924.22138 (Windows package 26.924.2738.0) with [windows] sandbox = "elevated". The sandbox log reported runtime read/execute validation failed: CreateFileW could not open a 283-character path under the CUA runtime’s js-dependency-cache. As a result, local commands failed before launch with helper_unknown_error: setup refresh had errors.

GLM-5.3 found the culprit hiding at the end of a very long hallway: 20 paths exceeding 260 characters across five unused runtime caches. After those regenerable caches were cleared, subsequent setup refreshes reported errors=[]; local commands and TXT file reading worked again, with the sandbox still elevated. This before-and-after result strongly implicates long-path handling, although it does not prove that the helper manifest is the sole cause.

Suggested prompt for another agent to fix:
"My Windows ChatGPT/Codex Desktop cannot run local commands or read local files and reports helper_unknown_error: setup refresh had errors. Please diagnose and repair this computer’s installation.
First inspect the latest Codex sandbox log and setup_error.json to identify the failing path and Win32 error. In particular, check for paths longer than 260 characters under %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node...\js-dependency-cache, and for runtime read/execute validation failed or CreateFileW failed in the log. GLM-5.3 found this failure pattern on another machine and restored it by clearing unused caches, but verify that my machine has the same cause before applying that workaround.
If the evidence matches, identify the active runtime and the inactive runtimes first. Make only a reversible change to confirmed inactive, regenerable caches, and record exactly what changed. Do not remove the active runtime, change ownership or ACLs, disable security controls, or switch the sandbox to unelevated without asking me. Restart the app, run a simple local command, read a local TXT file, and verify that a fresh sandbox setup refresh succeeds with errors=[]. If the evidence does not match, follow the logs to the actual cause instead of applying the cache workaround. Finish with the evidence, changes made, test results, and recurrence risk."

中文

确认此问题在 Codex Desktop 26.924.22138（Windows 包版本 26.924.2738.0）且配置为 [windows] sandbox = "elevated" 时仍会发生。沙箱日志显示 runtime read/execute validation failed：CreateFileW 无法打开 CUA 运行时 js-dependency-cache 中一条长达 283 字符的路径，随后所有本地命令都在启动前报 helper_unknown_error: setup refresh had errors。

**GLM-5.3 顺着这条“长得过分的走廊”找到了嫌疑点：**五个未使用的运行时缓存中共有 20 条超过 260 字符的路径。清理这些可重新生成的缓存后，后续沙箱初始化均显示 errors=[]，本地命令和 TXT 文件读取恢复，沙箱仍保持 elevated。清理前后的结果强烈指向长路径处理问题，但尚不能仅凭此断定 helper 清单是唯一原因。

给另一个 agent 来修复的提示词：

"我的 Windows 版 ChatGPT/Codex Desktop 无法运行本地命令或读取本地文件，提示 helper_unknown_error: setup refresh had errors。请帮我在这台电脑上诊断并修复。
先检查最新的 Codex 沙箱日志和 setup_error.json，确认具体失败路径与 Win32 错误。重点检查 %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node 下的 js-dependency-cache：是否存在超过 260 字符的路径，以及日志是否出现 runtime read/execute validation failed、CreateFileW failed。这是 GLM-5.3 在另一台电脑上找到并通过清理闲置缓存解决过的故障线索，不要未经验证就认定我的电脑也有同一根因。
如果证据吻合，请先辨认正在使用的运行时与闲置运行时，只对确认闲置、可再生成的缓存采取可恢复的处理方式，并记录改动。不要删除正在使用的运行时、修改文件所有权或 ACL、关闭安全防护，或擅自将沙箱改为 unelevated。处理后重新启动应用，实际测试一个简单本地命令和一个本地 TXT 文件读取，并确认新的沙箱日志显示 setup refresh 成功且 errors=[]。如果证据不吻合，继续根据日志寻找真实原因，不要套用缓存清理方案。最后告诉我根因证据、所做改动、测试结果和复发风险"

Still blocked on Windows 11.
Codex: 26.924.22138, build 11645, prod; updater reports up_to_date.
Commands fail before PowerShell starts.
setup_error.json contains only helper_unknown_error / “setup refresh had errors”.
The sandbox log reports CreateFileW failure during runtime read/execute validation.
Affected component: cua_node runtime ad3b5049246cde44, pnpm-store links for @rollup/plugin-typescript/12.1.2.
Owner inspection found the target and parent present, without reparse attributes.
The inspected ACLs include read/execute for CodexSandboxUsers.
Enabling long paths and fully restarting the app did not resolve the failure.
Feedback ID: 01a0dda7-530b-76e2-becd-89bbd4270e05
Please expose the underlying Windows error and provide a supported repair for this runtime that preserves projects, history and sandbox protections.

Moving the long path cache files out fixed it for me as well.
Codex desktop version 26.924.2738.0

Additional reproduction after an in-place Windows 10 → Windows 11 upgrade. The elevated sandbox worked before the OS change; this failure appeared only afterward.

Environment: Windows 11 Pro N, build 26200.9457; Codex Desktop package 26.924.2738.0; standalone CLI 0.157.1.
/setup-default-sandbox completed with “couldn't set up your sandbox.” The final sandbox log (2026-09-27) reports runtime read/execute validation failed / CreateFileW failed for an existing 283-character directory under %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime>\bin\node_modules\@oai\sky\dist\js-dependency-cache\...\@rollup\plugin-typescript\12.1.2\<hash>, followed by setup refresh had errors.
A read-only direct CreateFileW probe on that same directory returned Win32 error 3 with the ordinary path and succeeded (error 0) with the \\?\ extended-length prefix. The directory and its parent exist; inspected ACLs grant the sandbox group access; LongPathsEnabled=1.
The full setup attempt took roughly 2m40s and exited with the above error. Waiting longer or repeating it unchanged does not appear useful. The current unelevated setting lets local commands work but is only a fallback.
codex doctor reports the standalone install, auth, desktop app-server, and network healthy; it does not demonstrate that elevated sandbox provisioning succeeds.

No runtime caches or ACLs were modified during this reproduction. The Windows-version transition is new context for this issue; the long-path behavior is a strong diagnosis from the probe, not a claim that we inspected the setup helper’s internal source. A sanitized final log excerpt is available if maintainers need it.

Minimal, content-independent reproduction: the failure is triggered by path length alone, not by the CUA cache itself.

Environment: Windows 11 (build 26200), npm-installed CLI 0.155.1 and 0.158.0, [windows] sandbox = "elevated", LongPathsEnabled = 1. Probe = codex sandbox cmd /c echo OK (no model call).

1. Synthetic directory under the runtime root (unrelated to any Codex runtime):

$base = "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\zz_len_test"
function MakeDir($len) { $p = $base; while ($p.Length -lt $len) { $p += "\" + ("a" * [Math]::Min(40, $len - $p.Length - 1)) }; [IO.Directory]::CreateDirectory($p) | Out-Null }
MakeDir 250; codex sandbox cmd /c echo OK   # OK
MakeDir 270; codex sandbox cmd /c echo OK   # helper_unknown_error: setup refresh had errors
[IO.Directory]::Delete($base, $true); codex sandbox cmd /c echo OK   # OK

Longest path under `runtimes`	Result
250 chars	✅ OK
270 chars	❌ `setup refresh had errors` — the sandbox log names the synthetic path in `runtime read/execute validation failed … CreateFileW failed`
removed	✅ OK

2. Toggle test with the real stale cache (cua_node\<old hash>\…\js-dependency-cache, runtime 0.0.9, not used by the current app 0.0.24): moved out → OK, moved back → fails, moved out again → OK.

3. Uninstalling the desktop app does not help. After Remove-AppxPackage OpenAI.Codex, %LOCALAPPDATA%\OpenAI\Codex\runtimes stays on disk (it is outside the package), so the CLI keeps failing. Users who ever installed the desktop app are affected, even after removing it.

Where it comes from: ensure_runtime_tree_readable() first appears at tag rust-v0.155.0 (commit a974fa8cea, "Fix Windows sandbox identity and runtime permissions"; absent in rust-v0.154.0). It walks the tree with std::fs (long-path capable), then calls ACL helpers that use CreateFileW(to_wide(path)) / GetNamedSecurityInfoW without a \\?\ prefix. codex-windows-sandbox-setup.exe has no longPathAware in its manifest (checked in 0.155.1 and 0.158.0), so any entry ≥ 260 chars fails, and that single failure makes the whole setup refresh fatal.

Possible fixes: use \\?\-prefixed paths in the ACL helpers, and/or declare longPathAware in the helper manifests; and do not make a per-entry failure inside a runtime tree fatal for every sandboxed command.

Related: #46388, #47892, #48062.

Codex Desktop Windows: workaround for `helper_unknown_error: setup refresh had errors`

I ran into an issue with the Codex Desktop app on Windows where basically every workspace command stopped working.

Even very simple commands such as:

Get-Location

failed before they actually started.

Codex reported errors similar to:

helper_unknown_error: setup refresh had errors

and in some cases:

trusted Node process exited unexpectedly; kernel reset

After checking the Codex sandbox logs, I found that the actual failure was inside one of Codex's own cua_node runtimes.

Symptoms

My sandbox log repeatedly contained:

runtime read/execute validation failed

followed by:

CreateFileW failed

The failing path was inside:

C:\Users\<username>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<runtime-id>\

In my case, the problematic runtime ID was:

b58ca2eaa616c2da

The failing path was extremely deeply nested inside Codex's bundled Node dependency cache.

At the same time, Codex was already launching a different/newer cua_node runtime, which suggested the broken one was stale but was still being scanned during Windows sandbox initialization.

Step 1 — Check your sandbox log

Close Codex Desktop first.

Open PowerShell and run:

Get-ChildItem "$env:USERPROFILE\.codex\.sandbox" -Filter "*.log" |
Sort-Object LastWriteTime -Descending |
Select-Object -First 1 |
Get-Content -Tail 100

Look for something similar to:

runtime read/execute validation failed
CreateFileW failed for C:\Users\...\OpenAI\Codex\runtimes\cua_node\<runtime-id>\...
setup refresh completed with errors

Pay attention to the runtime ID directly after:

cua_node\

For example:

cua_node\b58ca2eaa616c2da

Do not automatically use my runtime ID. Use the one shown in your own log.

Step 2 — Back up the problematic runtime

I recommend moving it instead of deleting it immediately.

Create a backup folder:

New-Item -ItemType Directory -Force "$env:USERPROFILE\CodexRuntimeBackup"

Then move the failing runtime.

Replace <runtime-id> with the runtime ID from your log:

Move-Item `
  "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node\<runtime-id>" `
  "$env:USERPROFILE\CodexRuntimeBackup\<runtime-id>"

For example, mine was:

Move-Item `
  "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node\b58ca2eaa616c2da" `
  "$env:USERPROFILE\CodexRuntimeBackup\b58ca2eaa616c2da"

If you get an Access Denied error, close PowerShell and retry from PowerShell running as Administrator.

Step 3 — Verify the move

Check that the runtime no longer exists in the active Codex runtime directory:

Test-Path "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node\<runtime-id>"

Expected result:

False

Then check the backup:

Test-Path "$env:USERPROFILE\CodexRuntimeBackup\<runtime-id>"

Expected result:

True

Step 4 — Restart Codex

Open Codex Desktop again.

Try a basic command:

Run Get-Location and show me the output.

Mine started working immediately.

I then tested:

Run git status and show me the output.

The command runner worked normally.

If git status says:

fatal: not a git repository

that is a separate Git message. It means the current project does not contain a .git repository. The important thing is that Codex successfully ran the command.

Step 5 — Confirm the sandbox is healthy

Run:

Get-ChildItem "$env:USERPROFILE\.codex\.sandbox" -Filter "*.log" |
Sort-Object LastWriteTime -Descending |
Select-Object -First 1 |
Get-Content -Tail 60

Before the fix, mine contained:

runtime read/execute validation failed
CreateFileW failed
setup refresh completed with errors

After moving the stale runtime, it changed to:

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

That confirmed the Windows sandbox was initializing normally again.

Important notes

This is a workaround for the specific situation where the sandbox log points to a failing path under:

...\OpenAI\Codex\runtimes\cua_node\...

with:

runtime read/execute validation failed
CreateFileW failed

If your log instead points to a project folder, .git, .agents, or another ACL/permission problem, your root cause may be different.

I would also recommend moving the runtime first rather than deleting it. Keep the backup for a few days until you know Codex is stable.

In my case, removing the stale runtime from Codex's active runtime directory completely resolved the command-runner failure.[

codex_windows_setup_refresh_workaround_log.txt

](url)

Confirming the same failure in the ChatGPT/Codex desktop app on Windows 11 (2026-09-29). Every command in the native elevated Windows sandbox, including Get-Location, failed before launch with helper_unknown_error: setup refresh had errors. The log repeatedly reports:

runtime read/execute validation failed: validate runtime read/execute access on
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_modules\@oai\sky\dist\js-dependency-cache\shared-v1\applied-bk-agent-openai-js\pnpm-store\v11\links\@rollup\plugin-typescript\12.1.2\<hash>:
CreateFileW failed

The failing path is 291 characters. It is an existing ordinary directory (not a symlink). PowerShell Test-Path -LiteralPath returns True for both the normal path and its \\?\ extended-length form. icacls shows inherited (OI)(CI)(RX) for the local CodexSandboxUsers group, with no explicit deny on that directory.

Switching only [windows] sandbox from elevated to unelevated and restarting the desktop app restored command execution in multiple chats. sandbox_mode = "workspace-write" remained in place. No ACL or runtime-cache changes were made. This points to elevated sandbox runtime validation rather than a project-specific permission issue. The log does not expose a Win32 error code for CreateFileW, so the exact cause cannot be confirmed from this report.

I can independently reproduce this on Windows 11 Pro x64, build 26200.

The failure occurs with Codex 0.155.1, 0.157.1, 0.158.0, and 0.159.0. Reverting to 0.154.0 previously restored successful sandbox setup.

The repeated error is:

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

The sandbox log identifies CreateFileW failed while validating a directory beneath:

...\OpenAI\Codex\runtimes\cua_node\<runtime\bin\node_modules\@oai\sky\dist\js-dependency-cache\shared-v1\...

The failing path is 287 characters long. The directory exists, is not a reparse point, and CodexSandboxUsers already has Read & Execute access. LongPathsEnabled is enabled, and Codex is configured with [windows] sandbox = "elevated".

This appears to be addressed by PR #49058, merged as commit [df3e439](https://github.com/openai/codex/commit/df3e439c02efc90f29a26d2d602a54eea2e8a91e).

I verified that stable rust-v0.159.0 does not contain that commit, while rust-v0.160.0-alpha.6 does. My 0.159.0 installation still reproduces the failure.

Could this PR be linked to this issue, and could the maintainers confirm which stable Codex CLI and Codex Desktop releases will include the fix? I have not modified the runtime cache or independently tested the prerelease yet.

Update: Windows Desktop package OpenAI.Codex_26.1002.7124.0 still fails before commands start with “helper_unknown_error: setup refresh had errors.” The setup helper exits 1.

At 2026-10-09 11:50 UTC, the log reports OS error 32 on VCRUNTIME140_1.dll inside cua_node/3dd31cfff853001c. Earlier failures named node_repl.exe. A reboot and graceful app quit/reopen did not restore execution. An exact-DLL Process Explorer search now returns no matches; the locking process is unconfirmed.

Feedback ID: 01a118d5-beec-77cc-8668-2be75acc60d9.

Could maintainers confirm the supported Desktop/MSIX build containing #51822, or a supported recovery with rollback that preserves local data and sandbox protections?

Navigation Menu

Repository navigation

Windows sandbox provisioning fails on stale CUA dependency-cache paths over 260 characters #46255

Summary

Environment

Observed behavior

Root-cause evidence

Reversible workaround that restored operation

Expected behavior

Additional notes

Codex Desktop Windows: workaround for `helper_unknown_error: setup refresh had errors`

Symptoms

Step 1 — Check your sandbox log

Step 2 — Back up the problematic runtime

Step 3 — Verify the move

Step 4 — Restart Codex

Step 5 — Confirm the sandbox is healthy

Important notes

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows sandbox provisioning fails on stale CUA dependency-cache paths over 260 characters #46255

Description

Summary

Environment

Observed behavior

Root-cause evidence

Reversible workaround that restored operation

Expected behavior

Additional notes

Activity

github-actions commented on Sep 17, 2026

strbel commented on Sep 26, 2026

kanakayya commented on Sep 26, 2026

AkiraKirizaki commented on Sep 26, 2026

helloworld1631 commented on Sep 26, 2026

kanakayya commented on Sep 27, 2026

TheGreyFoxBaby commented on Sep 27, 2026

BrightPhoenix77 commented on Sep 27, 2026

sung-ho-oh commented on Sep 28, 2026

colinljy commented on Sep 28, 2026

Codex Desktop Windows: workaround for helper_unknown_error: setup refresh had errors

Symptoms

Step 1 — Check your sandbox log

Step 2 — Back up the problematic runtime

Step 3 — Verify the move

Step 4 — Restart Codex

Step 5 — Confirm the sandbox is healthy

Important notes

NailZI commented on Sep 29, 2026

omarc1492 commented on Sep 29, 2026

kanakayya commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Codex Desktop Windows: workaround for `helper_unknown_error: setup refresh had errors`