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:

1. use extended-length Windows paths when validating runtime trees; or
2. 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.

Start with the Windows sandbox helper's runtime-tree validation and reproduce the failure using the stale js-dependency-cache paths described in the report. Check the provided diagnostic script or sanitized logs if maintainers share them; done means stale inactive caches no longer abort provisioning, sandboxed commands and computer use work, and codex doctor reports passing checks.