[Windows] Regression in CLI 0.155.0: elevated sandbox initialization fails during runtime path validation; 0.154.0 works

What version of the Codex App are you using (From “About Codex” dialog)?

CLI 0.155.0

What subscription do you have?

pro

What platform is your computer?

OS: Windows 10 Pro 22H2, build 19045.6456, x64 Affected Codex CLI version: 0.155.0 Working Codex CLI version: 0.154.0 Installation method: npm global installation (@openai/codex) Shells tested: PowerShell 7.6.6, PowerShell 7.5.11, and cmd.exe Windows sandbox implementation: elevated Sandbox mode: workspace-write Approval policy: on-request Windows LongPathsEnabled: 1

What issue are you seeing?

After updating Codex CLI to 0.155.0 on Windows, sandboxed commands consistently fail during elevated sandbox initialization, before the requested command starts. Even a simple read-only command such as Get-Date cannot run.

The error returned is:

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

The sandbox log identifies a failure while validating read/execute access to a directory inside Codex's own cua_node runtime dependency cache:

runtime read/execute validation failed:
validate runtime read/execute access on <runtime-cache-path>:
CreateFileW failed for <runtime-cache-path>

setup error: setup refresh had errors

The affected path is shown below with the Windows username redacted. The original, unredacted path is 291 characters long:

C:\Users\<USER>\AppData\Local\OpenAI\Codex\runtimes\cua_node\b58ca2eaa616c2da\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\bf978194e78e4126a616bfdc5a9fea913609f48ddc1a68ce028d4322c58982dd

This directory exists and is a regular directory, not a symbolic link.

codex doctor --summary reports:

✓ install      consistent
✓ config       loaded
✗ sandbox      elevated Windows sandbox provisioning recorded a structured failure

Downgrading the npm-installed CLI to 0.154.0 restored sandboxed command execution and workspace file read/write operations while retaining windows.sandbox = "elevated".

What steps can reproduce the bug?

Observed on my existing Windows installation:

Install Codex CLI 0.155.0:
```
npm install -g @openai/codex@0.155.0
```

Use the following configuration:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[windows]
sandbox = "elevated"

Restart Codex and request a simple sandboxed command, such as Get-Date.

Observe that sandbox initialization fails with:

helper_unknown_error: setup refresh had errors

Exit Codex and downgrade:
```
npm install -g @openai/codex@0.154.0
```
Restart Codex with the same sandbox configuration and repeat the test.

Result: On 0.154.0, sandboxed commands succeed. Creating, reading, and removing a temporary file inside the workspace also succeeds.

This has been reproduced on my existing installation containing the runtime cache described above; I have not tested a clean Windows installation.

What is the expected behavior?

No response

Additional information

Troubleshooting performed:

Restarted Codex and rebooted Windows: no improvement.
Reinstalled CLI 0.155.0: no improvement.
Replaced PowerShell 7.6.6 with 7.5.11: no improvement.
Tested cmd.exe instead of PowerShell: the same sandbox initialization failure.
Commands outside the sandbox run successfully.
Downgraded to CLI 0.154.0: sandbox command execution and workspace read/write recovered without switching to unelevated.

Possible long-path handling issue — not yet confirmed as the root cause:

The original failing directory path is 291 characters long.
Windows LongPathsEnabled is already set to 1.
A read-only CreateFileW probe under my current Windows user failed for the ordinary path with Win32 error 3.
The same probe succeeded when the path was prefixed with \\?\, without changing permissions.
The inspected directory and parent ACLs contain allow entries for CodexSandboxUsers; no explicit deny entries were found in those inspected ACLs.
The embedded application manifest inspected in codex-windows-sandbox-setup.exe did not contain a longPathAware declaration.

The path-opening probe was performed under my current user, not the sandbox account, so it does not fully rule out sandbox-token or effective-permission issues.

The confirmed observation is the version-dependent behavior: 0.155.0 fails on this machine, while 0.154.0 works. Long-path handling during runtime validation is a suspected trigger, not a confirmed implementation-level diagnosis.

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

Powered by Codex Action

Source-side this lines up very tightly with #46255 / #46326 and one specific 0.155 change.

rust-v0.154.0 points to 6b9826e3…. Commit 2833985d88389c0812f32560a8c793920fda34f2 (“Repair Windows sandbox access to existing runtime children”, #46241), merged Sep 17 before rust-v0.155.0 (f0a1b8f0…), added ensure_runtime_tree_readable(): it recursively walks %LOCALAPPDATA%\OpenAI\Codex\runtimes, applies/validates ACLs on every descendant, and promotes a descendant failure to runtime read/execute validation failed / setup refresh failure.

The relevant ACL path is also a strong match for the reporter’s long-path discriminator: path_mask_allows() reaches fetch_dacl_handle(), which calls CreateFileW(to_wide(path)); the current to_wide() only UTF-16 encodes + NUL-terminates the supplied path and does not add an extended-length \\?\ prefix. The new grant path likewise starts from the same DACL-handle helper. So “ordinary path fails, \\?\ succeeds” is on the newly introduced traversal path, rather than only a generic long-path suspicion.

A useful regression would create a nested runtimes descendant beyond the legacy path limit and exercise both cases: (1) its ACL is already sufficient, and (2) it needs the new read/execute grant. Setup should traverse/check/grant/verify without turning that descendant into a global refresh failure. That would cover both the check and repair branches rather than only the tree walk itself.

This looks likely duplicate-family evidence for #46255, but the source/release linkage may make the 0.154 → 0.155 regression boundary easier to pin.

Additional corroborating report from a Windows / PowerShell setup using the npm-installed Codex CLI:

CLI 0.155.1 showed the same runtime-cache validation symptoms discussed here, causing repeated requests to run commands outside the sandbox.
During troubleshooting, the affected runtime-cache entry was found to be an ordinary directory with explicit read/execute allow permissions for CodexSandboxUsers.
After rolling back to CLI 0.154.0 and restarting with the existing sandbox settings, Get-Location executed successfully inside the workspace-write sandbox (exit code 0), without an approval request.

This corroborates the version-dependent regression through 0.155.1. Long-path handling remains a suspected explanation for this setup, not a confirmed root cause. The post-rollback check reported here was limited to Get-Location; it was not a full sandbox test suite.

i can confirm i have the same issue with codex cli on windows started at 0.155, im using 0,154 for now as a workaround

Confirming a matching failure on Windows 11 (OS build 26200) with npm-installed Codex CLI 0.155.1, and confirming that downgrading to 0.154.0 resolves sandbox command execution in our environment.

On 0.155.1:

Even read-only workspace commands failed before execution with helper_unknown_error: setup refresh had errors.
The sandbox log reported runtime read/execute validation failed / CreateFileW failed for a 283-character directory path under Codex's cua_node runtime dependency cache, ending in pnpm-store\v11\links\@rollup\plugin-typescript\12.1.2\<hash>.
The directory existed, and its ACL included read/execute permission for CodexSandboxUsers. Workspace permission setup completed successfully.
Enabling LongPathsEnabled = 1 and rebooting Windows did not resolve the failure.
A read-only CreateFileW probe under the current user failed with the ordinary path (Win32 error 3), but succeeded with the extended-length \\?\ prefix.
Inspection of the sandbox setup helper's embedded manifest found no longPathAware declaration.

After downgrading, codex --version reports codex-cli 0.154.0. A command executed successfully inside the sandbox, returned the expected workspace directory, and accessed README.md metadata without an elevation request. We have not yet tested sandbox write access after the downgrade.

Long-path handling remains a suspected trigger, not a confirmed implementation-level diagnosis: the path probe ran under the current user rather than the sandbox account. The version-dependent failure and successful sandbox retest after downgrade are confirmed.

Windows sandbox setup fails on a bundled runtime path longer than MAX_PATH despite LongPathsEnabled=1

Additional reproduction for #46388,
not a duplicate new issue.
Matching upstream report: #46255.
Both were OPEN when checked on 2026-09-21 KST. Other reporters corroborate 0.155.1 failures;
we did not independently reproduce their reported successful downgrade to 0.154.0.

Impact

Normal sandboxed commands and built-in apply_patch reads repeatedly fail before the requested
operation starts. This blocks development and prompts repeated troubleshooting/retries,
consuming user time and subscription allowance. The affected user reports substantial loss
of time and usage; precise token or monetary loss was not exposed and is not estimated here.
Other matching reports exist in the linked issues; total prevalence is unknown.

The user's primary concern is collective resource waste, not compensation: when each
affected user independently repeats diagnosis, retries, upgrades and restarts for the same
product defect, human time and model inference resources are repeatedly spent without
advancing the intended work. Aggregate impact is not measured here, but the repeated
failure pattern warrants a product-level fix and interim safeguards rather than requiring
each user to rediscover a workaround.

Environment

Windows 11, PowerShell, Codex CLI used in a VS Code terminal.
Installed/running npm Codex CLI: 0.155.1; npm latest also returned 0.155.1 at diagnosis.
windows.sandbox = "elevated".
Registry LongPathsEnabled = 1.
Separately installed Codex tool runtime: cua_node/1d17ec7e898678cb.
Its node_repl configuration uses a bundled 0.149.0-alpha.4.3 child Codex. The failing
setup refresh itself launches the npm CLI's 0.155.1 sandbox setup helper.
Updating CLI and restarting VS Code did not resolve it.

Actual behavior

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

apply_patch verification failed: Failed to read file to update ...
fs sandbox helper failed with status exit code: 1:
windows sandbox failed: helper_unknown_error: setup refresh had errors

Sanitized setup-log excerpt:

runtime read/execute validation failed: validate runtime read/execute access on
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\1d17ec7e898678cb\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:
CreateFileW failed for [same path]
setup refresh completed with errors: [runtime read/execute validation failed ...]
setup error: setup refresh had errors
setup refresh: exited with status ExitStatus(ExitStatus(1))

The failing directory's expanded path was 281 characters; the deepest file was 313.
The directory and file existed. An ordinary PowerShell process could read them.

Reproduction observed on the affected installation

Keep the installed tool runtime listed above and elevated sandbox enabled.
Confirm LongPathsEnabled=1, update CLI to 0.155.1, restart VS Code.
Ask the agent to run a non-allowlisted command with default permissions.
Attempt a built-in apply_patch create → modify → delete on a disposable workspace file.
Creation can succeed, but file reads for modify/delete fail; inspect the sandbox log.

This exact reproduction depends on the installed runtime layout. A clean-machine Codex
installation reproduction has not been performed.

Supporting Windows API experiment

The setup helper's extracted application manifest had asInvoker but no longPathAware.
Its Authenticode signature was valid.
A separate compiled executable without a long-path manifest called CreateFileW with
READ_CONTROL, share flags 7, OPEN_EXISTING and FILE_FLAG_BACKUP_SEMANTICS on that directory:

ordinary path: length=281, success=false, GetLastError=3
\\?\-prefixed path: length=285, success=true, GetLastError=0

The same API call hosted in PowerShell succeeded for both path forms. This supports a
long-path compatibility diagnosis rather than a missing directory. We have not audited
the implementation's exact CreateFileW call site or instrumented its GetLastError.

Controlled local workaround and outcome

For diagnosis/recovery, copied the identical 1,426-byte tslib module to
dist/compat-deps/tslib.es6.js, replaced only its import specifier in 37 bundled JS files,
and retained the original cache and JS files outside the scanned runtime for rollback.
The runtime's maximum file path became 183 characters.

All 37 importers passed Node syntax checks; fresh imports of @oai/sky and
@oai/sky/service succeeded.
A default-mode command then executed as the dedicated CodexSandboxOffline account.
Built-in apply_patch create → modify → delete succeeded, including cleaning the prior probe.
Consecutive setup refresh entries reported errors=[].
No signed executable, sandbox policy, model/provider setting or permission was changed.
The setup executable retained a valid signature.

This is a local packaging workaround, not a proposed requirement for end users to edit
vendor files. Runtime reinstall/update may restore the long paths.

Requested upstream investigation

Please inspect extended-length path handling in runtime read/execute validation, and the
setup helper's long-path manifest/build settings. Add a regression case with a real directory
over 260 characters while keeping the elevated sandbox enabled. Runtime packaging could
also avoid deeply nested build-cache import paths. Including GetLastError and the failing
path length in diagnostics would make this substantially cheaper for users to diagnose.

Please also detect this known failure signature early, stop redundant automatic retries,
and surface a clear actionable diagnostic and verified mitigation while a fix is pending.
The request is to prevent repeated waste across affected users, not to seek reimbursement.

Privacy

This report omits usernames, machine names, project paths, source media, session transcripts,
credentials and sandbox secrets. Only generic errors and shipped runtime-relative paths are
included. No full configuration or unredacted log is attached.

Confirmed on Codex 0.155.1 on Windows using the elevated sandbox path.

Sandboxed commands fail consistently before the requested command starts with:

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

The sandbox log reports the same runtime validation failure:

runtime read/execute validation failed:
validate runtime read/execute access on C:\Users\<USER>\AppData\Local\OpenAI\Codex\runtimes\cua_node\e7fe122ad3cbcd58\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\bf978194e78e4126a616bfdc5a9fea913609f48ddc1a68ce028d4322c58982dd:
CreateFileW failed

Additional confirmation:

The affected path is 283 characters long.
The directory exists and is a regular directory.
LongPathsEnabled=1.
The directory ACL includes inherited read/execute access for CodexSandboxUsers.
The embedded manifest in codex-windows-sandbox-setup.exe contains no longPathAware declaration.
Repeating the same command outside the sandbox succeeds, so the command, shell, Git, and workspace are not the failing components.
Restarting and retrying do not resolve the failure.

This appears to be the same 0.155.x regression and long-path validation trigger. The durable fix likely needs either a longPathAware manifest on the setup helper or extended-length \\?\ path handling during runtime validation.

same problem and confirmed 0.154 can solve it

Additional reproduction on Codex CLI 0.156.0, Windows 10 Home build 19045, native elevated sandbox. The same failure survived an upgrade from 0.155.0. Here LongPathsEnabled = 0 (unlike the original report's value of 1).

On 2026-09-18 and 2026-09-23, %USERPROFILE%\.codex\.sandbox\sandbox.<date>.log repeatedly identified a 291-character directory in Codex's own CUA Node runtime cache as the read/execute validation target, with CreateFileW failed, setup refresh completed with errors, and setup error: setup refresh had errors. The shape is C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<hash>\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>. The failed target is not inside the D: workspace.

The identical read-only Get-Content command failed before process creation in the normal sandbox (helper_unknown_error: setup refresh had errors) but succeeded immediately outside the sandbox. For the exact logged runtime directory, ordinary Test-Path returned false, while an extended-length \\?\ path succeeded (Directory.Exists = True; attributes: ordinary Directory). On 2026-09-23 an early refresh succeeded, followed by repeated failures. This suggests that which runtime roots are included in a refresh may affect reproducibility.

The Win32-path versus extended-path observation strongly supports a long-path handling problem during runtime validation, but I have not traced the setup binary's exact CreateFileW flags or token. No registry, sandbox configuration, or runtime cache changes were made. Could maintainers confirm whether this runtime validation uses extended-length paths or a long-path-aware binary? Separately, apply_patch sometimes reports a false reparse point on ordinary workspace files; I will provide that evidence on #46290 rather than assume the two errors share one cause.

Follow-up controlled regression test after downgrading to Codex CLI 0.154.0 (2026-09-23). The installed codex.exe --version and npm package metadata both report 0.154.0; this is not merely the command-runner cache filename.

The environment remains Windows native sandbox = "elevated" with LongPathsEnabled = 0. The previously failing CUA Node cache directory still has a 291-character path. Ordinary Win32/.NET path access to that exact directory still fails, while \\?\ extended-length access succeeds. Thus the prior long-path condition was not removed by changing the OS setting or deleting the cache.

In the same workspace, 12/12 independent sandboxed read-only commands succeeded, alternating reads of Development_Log.md and a skill file outside the project. During that window, the sandbox log recorded 13 independent refreshes, all errors=[], with no new runtime read/execute validation failed, CreateFileW failed, or setup refresh had errors. Subsequent read-only path and log-tail checks also succeeded. The current 0.154.0 binary timestamp was approximately 07:46 local time, tests began around 07:52, and the day's earlier errors ended at 06:26:40 local time; they were not part of this test window.

This confirms that the command-start failure did not reproduce in this limited 0.154.0 run while its apparent trigger remained present. It does not establish permanent resolution or isolate the exact implementation change; the validated runtime-root set may differ. No apply_patch write test was performed, so the separate false reparse-point symptom remains unverified on 0.154.0.

Windows sandbox setup fails validating a long path in the bundled CUA runtime

Component: Codex CLI 0.156.1, Windows x86_64, elevated Windows sandbox.

Existing reports checked 2026-09-23

Windows sandbox provisioning fails on stale CUA dependency-cache paths over 260 characters #46255 (open): same CUA cache path,
long-path probe results and absent long-path manifest.
[Windows] Regression in CLI 0.155.0: elevated sandbox initialization fails during runtime path validation; 0.154.0 works #46388 (open): same runtime-validation
regression, with additional reports through 0.156.0 and user-reported
recovery on 0.154.0. That downgrade has not been tested here.

Do not file a duplicate. Any submission should be a concise additional
reproduction on 0.156.1, after the owner authorizes posting.

Additional verification

codex sandbox -- powershell.exe -NoProfile -Command Get-Location failed
with the same setup error, independently of aimem or a model invocation.

Matching public source at tag rust-v0.156.1:

codex-rs/windows-sandbox-rs/src/acl.rs, fetch_dacl_handle: the
CreateFileW flags match the separate probe exactly; error handling omits
GetLastError.
src/winutil.rs, to_wide: UTF-16 encoding plus NUL, no path normalization.
src/setup_provisioning/setup_runtime_bin.rs: recursively validates runtime
children using grant_read_execute_aces, with the observed diagnostic.
codex-windows-sandbox-setup.manifest: no longPathAware declaration.

This strengthens the diagnosis but is not a patched-helper A/B test or a
clean-machine synthetic reproduction. Neither has been performed yet.

Impact and reproduction

With the bundled computer-use runtime installed, ask Codex to execute a harmless
PowerShell command such as Get-Location under the normal sandbox. The command
never starts. This reproduced in several checkouts on the same host.

Tool error:

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

The sandbox log reports read ACL run completed, followed by:

runtime read/execute validation failed:
validate runtime read/execute access on <runtime-cache-directory>:
CreateFileW failed for <runtime-cache-directory>
setup refresh completed with errors

The failing directory has this structure (user and hashes redacted):

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-hash>\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\<64-character-hash>

The expanded original path is 281 characters, excluding the terminating NUL.

Observed evidence

The directory exists, is not a symlink, and can be enumerated by the operator.
Its ACL includes CodexSandboxUsers: ReadAndExecute, Synchronize.
System LongPathsEnabled is already 1.
The installed codex-windows-sandbox-setup.exe has an embedded manifest;
inspection did not find a longPathAware declaration.
A separate small C# console executable without a long-path-aware manifest
called CreateFileW on this exact directory using READ_CONTROL (0x20000),
share flags 7, OPEN_EXISTING (3), and FILE_FLAG_BACKUP_SEMANTICS (0x02000000).
The ordinary 281-character path failed with Win32 error 3. Prefixing the
same path with \\?\ succeeded (285 characters). Handles were closed.
Calls from Python and the PowerShell host succeeded with the ordinary path;
the failure therefore depends on the calling process, not merely existence.
codex doctor --summary --ascii --no-color reports an otherwise consistent
installation and a structured elevated-sandbox provisioning failure.

Suspected cause, not yet proven in the helper

The evidence points to a long-path handling defect in runtime permission
validation. The standalone reproducer does not instrument the actual helper:
its log omits the underlying Win32 error, so the helper's exact failing API
arguments and error still need confirmation.

Expected: sandbox initialization handles the paths shipped/generated by the
bundled runtime, then launches the requested command.

Please check extended-length path normalization and/or the helper's long-path
manifest, include the Win32 error in this diagnostic, and add a regression
covering runtime directories beyond MAX_PATH.

No ACL, sandbox-policy, registry, runtime-cache or binary modifications were
made during diagnosis. No verified repair yet. This report omits credentials,
hostnames, project names, conversation links and full configuration files.

chore: pin @openai/codex to "0.154.0"

Additional reproduction on npm-installed Codex CLI 0.156.0, Windows/PowerShell.

Even Write-Output 'LOCAL_EXECUTOR_OK' fails before process creation with:

helper_unknown_error: setup refresh had errors

The failure also occurs with the working directory set to Temp, with login=false. Disabling node_repl and starting with --no-daemon did not resolve it.

Sandbox logs show runtime read/execute validation failed and CreateFileW failed for a 291-character path inside the bundled cua_node cache, ending in @rollup/plugin-typescript/12.1.2/<hash>.

I uploaded diagnostics through Codex feedback. Thread ID:

01a0cbf2-74fb-7873-bddb-0dee581d449b

I have not tested downgrading to 0.154.0. Please advise on a supported fix that preserves sandbox protections.

Merge pull request #45 from Max-Lough/fix/codex-runtime-walk-standin

Additional reproduction on npm-installed Codex CLI 0.156.1, Windows build 22631.6199 (23H2), native PowerShell launched from Visual Studio. Diagnosis performed September 24, 2026.

The elevated sandbox fails before even a harmless echo command starts, in both an existing Git worktree and its parent repository:

codex sandbox -P :read-only -C '<workspace>' -- cmd.exe /d /c echo SANDBOX_PROBE_OK

Result: windows sandbox failed: helper_unknown_error: setup refresh had errors.

The sandbox log reports runtime read/execute validation failed followed by CreateFileW failed on this existing, ordinary directory (username omitted):

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\b474a88d5d105afa\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\bf978194e78e4126a616bfdc5a9fea913609f48ddc1a68ce028d4322c58982dd

The actual expanded directory path is 287 characters; its descendant node_modules\tslib\tslib.es6.js is 319 characters.

Additional evidence:

LongPathsEnabled = 1.
The inspected runtime root and failing directory ACLs grant CodexSandboxUsers ReadAndExecute/Synchronize.
The installed setup helper's embedded manifest has no longPathAware element.
A separate C# executable without long-path opt-in, running as the current user, called CreateFileW with READ_CONTROL, share flags 7, OPEN_EXISTING, and FILE_FLAG_BACKUP_SEMANTICS. The ordinary path failed with Win32 error 3; adding \\?\ succeeded. Hosting the same call in PowerShell succeeded with both forms. This supports a long-path diagnosis but does not instrument the actual sandbox helper or test its token.
Temporary notify=[] and mcp_servers.node_repl.enabled=false overrides did not resolve the elevated-sandbox failure.
The runtime is still referenced by the CLI configuration, and the installed Sky JavaScript directly imports this exact tslib path. This is not safely disposable cache merely because its directory is named js-dependency-cache.

A single-command test of the documented fallback succeeded (exit code 0, expected output):

codex sandbox -P :read-only -c 'windows.sandbox=unelevated' -C '<workspace>' -- cmd.exe /d /c echo SANDBOX_PROBE_OK

The saved sandbox setting remains elevated. No runtime files, ACLs, registry settings, or signed binaries were manually patched. A CLI downgrade was not tested here.

Please include this runtime layout in regression coverage for long-path handling during elevated sandbox setup.

@PPRRLLRR

Additional cross-reference from #44696:

@PPRRLLRR reproduced the same lower-level runtime-validation shape on Codex CLI 0.156.0:

runtime read/execute validation failed
-> cua_node / @oai/sky / js-dependency-cache / pnpm-store / @rollup/plugin-typescript / <hash>
-> CreateFileW failed
-> setup refresh had errors

The historical failing path length was 282 characters.

A later read-only check could not perform the normal-vs-\\?\ A/B because that exact historical runtime object was no longer present (both ordinary and extended-length lookups returned absent), so this is not an independent proof of the long-path mechanism on that host.

However, the path shape, length range, version (0.156.0), and underlying sandbox-log failure closely match the long-path/runtime-validation cluster documented here and in #46255.

This looks like another corroborating reproduction of the same cluster rather than the separate Temp/AppData ACL failure mode tracked in #43373.

I can reproduce what appears to be the same Windows sandbox/setup-refresh failure.

Environment:

Windows 10 Pro
Windows Version: 2004
OS Build: 19041
ChatGPT/Codex Desktop package: OpenAI.Codex_26.924.2738.0
Codex CLI: 0.152.1

Symptom:

Even a simple command such as Get-Location fails before the command is actually executed:

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

The sandbox log shows that setup refresh fails during runtime read/execute validation with a CreateFileW failed error.

The failing target is under:

...\AppData\Local\OpenAI\Codex\runtimes\cua_node\415ffebf3d576e9b...\pnpm-store\v11\links@rollup\plugin-typescript\12.1.2<64-character-hash>

The full path is approximately 291 characters long.

I also tested access to the same target from PowerShell:

Normal path: Test-Path = False
Extended-length (\\?\) path: Test-Path = True
Windows LongPathsEnabled is currently 0

An important observation is that Codex was working normally on this same machine and primary workspace before this started happening.

The earlier sandbox log repeatedly used:

...\OpenAI\Codex\bin\d375f7df50d3b421\codex-windows-sandbox-setup.exe

and reported successful setup refreshes:

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

After the problem appeared, different sandbox setup builds were being used (including faa963e871dd422c), and setup refresh now fails during runtime read/execute validation.

I also reproduced the same failure in a separate, nearly empty workspace, so this does not appear to be specific to the original project/workspace.

To keep the diagnostic environment clean, I have NOT:

modified LongPathsEnabled
modified ACLs manually
deleted or modified the cua_node runtime/cache
deleted/recreated .codex
applied any filesystem workaround

I can provide additional sanitized sandbox log excerpts if useful.

Additional cross-machine reproduction:

I have now reproduced the same failure independently on a second machine running Windows 11, using a different Codex project that has not started development.

On this Windows 11 machine, Codex was working earlier the same day. Earlier sandbox setup runs used:

...\OpenAI\Codex\bin\13995fba801849b0\codex-windows-sandbox-setup.exe

and completed successfully with:

setup refresh: processed 0 write roots (read roots delegated); errors=[]

Later, the sandbox setup build changed to:

...\OpenAI\Codex\bin\d23520d1e41bfb24\codex-windows-sandbox-setup.exe

After that, even Get-Location failed before execution with:

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

The Windows 11 sandbox log shows the same failure pattern as on my Windows 10 machine:

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

The failing path is again under:

...\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>

The two machines have different cua_node runtime IDs and different final hash directories, but both fail during validation of the same dependency structure.

Windows 10 runtime ID:
415ffebf3d576e9b

Windows 11 runtime ID:
b474a88d5d105afa

On the Windows 11 machine, the sandbox successfully processed the project write root before the overall setup failed due to the cua_node runtime validation error.

This gives me the same failure across:

Windows 10 and Windows 11
different machines
different projects/workspaces
ChatGPT/Codex Desktop
VS Code Codex (tested on the Windows 10 machine)

I have still not modified ACLs, the Codex runtime/cache, .codex, or Windows long-path settings as a workaround.

I can provide sanitized log excerpts from both machines if useful.

Additional reproduction / workaround data from another affected Windows 10 machine.

Environment

Windows 10 Pro, build 19041, x64
ChatGPT Desktop: OpenAI.Codex_26.924.2738.0
Codex CLI: 0.152.1
Failure: helper_unknown_error: setup refresh had errors

Observed sandbox failure

The sandbox log consistently failed during runtime read/execute validation inside:

C:\Users<USER>\AppData\Local\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\a522fe9000e9cb07598cb89328c5f87afda445b7562f1579b3d4e1f77197a142

The conventional path length was 291 characters.

The sandbox log reported:

runtime read/execute validation failed
CreateFileW failed

followed by:

setup error: setup refresh had errors
setup refresh: exited with status ExitStatus(ExitStatus(1))

The directory actually existed. Using the \?\ extended-length path allowed the same directory tree to be enumerated successfully.

LongPathsEnabled A/B test

Initially:

LongPathsEnabled=0

A direct read-only CreateFileW test against the 291-character ordinary path failed with Win32 error 3.

After temporarily changing:

LongPathsEnabled=1

and rebooting, the same direct CreateFileW test succeeded.

However, Codex sandbox initialization still failed with the same "setup refresh had errors" error.

Therefore, enabling Windows long paths alone did not resolve the Codex failure on this machine.

Runtime isolation test

I then moved only the affected runtime directory:

...\OpenAI\Codex\runtimes\cua_node\415ffebf3d576e9b

out of the active runtime tree into a quarantine directory. The runtime was not deleted.

Immediately afterward, the same installed Codex/Desktop sandbox setup succeeded:

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

Managed-shell execution also recovered.

I tested three separate projects/workspaces, and all three successfully executed a read-only working-directory command.

Control test

To separate the runtime isolation result from the Windows long-path registry change, I restored:

LongPathsEnabled=0

Then I rebooted Windows, left 415ffebf3d576e9b quarantined, and repeated the tests.

All three projects continued to work normally.

Observed A/B results:

affected runtime present + LongPathsEnabled=0
-> FAIL

affected runtime present + LongPathsEnabled=1
-> FAIL

affected runtime quarantined + LongPathsEnabled=1
-> PASS

affected runtime quarantined + LongPathsEnabled=0 + reboot
-> PASS

This suggests that the immediate blocker on this machine was the specific cached cua_node runtime / its validation path, rather than LongPathsEnabled itself.

I would still treat the implementation-level root cause as unconfirmed.

The deep runtime path / CreateFileW validation behavior appears to be involved, but the controlled result only establishes that removing this particular cached runtime from the active runtime tree restored sandbox initialization.

I have kept the failing runtime directory quarantined rather than deleting it in case additional diagnostics are useful.

Follow-up: I reproduced the same failure pattern on a separate Windows 11 machine and confirmed the same workaround.

Windows 11 observations:

Codex managed-shell command failed with:
Failed to create unified exec process:
helper_unknown_error: setup refresh had errors
LongPathsEnabled was 0 and was NOT modified during this test.

I enumerated the cua_node runtimes before making any changes.

Four runtimes showed:

ErrorCount = 0
MaxPathLen between 177 and 233

One runtime was different:

b474a88d5d105afa

ItemCount = 5134
ErrorCount = 1
MaxPathLen = 291

Its deepest successfully enumerated normal path was under the same dependency structure seen on the Windows 10 machine:

@OAI\sky\dist\js-dependency-cache\shared-v1\applied-bk-agent-openai-js\pnpm-store\v11\links@rollup\plugin-typescript\12.1.2<64-character hash>

This is notable because the failing runtime ID on Windows 10 was different:

Windows 10:
415ffebf3d576e9b
ItemCount = 5153
ErrorCount = 1
MaxPathLen = 291

Windows 11:
b474a88d5d105afa
ItemCount = 5134
ErrorCount = 1
MaxPathLen = 291

I then performed the same controlled isolation test on Windows 11.

I moved ONLY:

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

out of the active runtime tree into:

...\OpenAI\Codex\runtimes_quarantine\cua_node\b474a88d5d105afa

The runtime was not deleted.

No other changes were made:

LongPathsEnabled remained 0
no reboot
no ChatGPT/Codex reinstall
no cache cleanup
no changes to the other cua_node runtimes
no project files modified

Immediately after quarantining that runtime, the same Codex managed-shell command that had failed started working.

I then tested all Codex projects currently present on this Windows 11 machine:

iPAS AI project
-> PASS
Company-RAG project
-> PASS

Result: 2/2 projects passed.

So there are now two separate machines showing the same pattern:

Windows 10:
different cua_node runtime ID
-> ErrorCount = 1
-> MaxPathLen = 291
-> Codex setup refresh FAIL
-> quarantine affected runtime
-> Codex PASS

Windows 11:
different cua_node runtime ID
-> ErrorCount = 1
-> MaxPathLen = 291
-> Codex setup refresh FAIL
-> quarantine affected runtime
-> Codex PASS

This makes the issue appear not to be specific to a single cached runtime ID.

Both affected runtimes contain the same type of deep @OAI\sky / js-dependency-cache / pnpm-store / @rollup/plugin-typescript dependency path, and both recover when only the affected runtime is removed from the active runtime tree.

I am still treating the implementation-level root cause as unconfirmed, but this provides a second-machine reproduction with a different cua_node runtime ID and the same controlled recovery behavior.

Both failing runtimes have been preserved in quarantine in case additional diagnostics are useful.

Additional reproduction from Codex Desktop on Windows 11. This affects shell commands, Node REPL, and Computer Use in the same session.

Environment:

Codex Desktop UI version: 26.924.22138; MSIX package: OpenAI.Codex 26.924.2738.0
Bundled codex-cli: 0.158.0-alpha.2.1
Windows 11 Home, build 26200, x64
[windows] sandbox = "elevated"; LongPathsEnabled = 0
Fully quitting and restarting Codex repeatedly did not help.

Repro:

A trivial PowerShell or cmd command fails before process creation: helper_unknown_error: setup refresh had errors.
node_repl evaluating 1+1 reports trusted Node process exited unexpectedly; kernel reset, rerun your request.
Computer Use initialization fails with the same trusted Node process error.
The failures also appeared in another Codex chat at the same time.

Sandbox 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\<64-character hash>: CreateFileW failed, followed by setup refresh had errors. The actual directory exists; the absolute path length is 283 characters. I omitted the Windows username and runtime identifiers from this comment.

A read-only Win32 CreateFileW probe (FILE_READ_ATTRIBUTES, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS) on that exact directory returned error 3 with the conventional path, but succeeded with the \\?\ extended-length prefix. No ACLs, registry values, runtime files, or Codex config were changed.

One-off -c 'windows.sandbox="unelevated"' tests successfully ran cmd.exe /c echo SANDBOX_OK and launched the bundled node_repl.exe --help; full Desktop Computer Use behavior under unelevated mode has not been tested. This appears to be the same elevated sandbox runtime-path validation failure reported here, still present in this newer bundled CLI.

Follow-up: the command-start failure recurred on Codex CLI 0.157.1 (2026-09-27). I plan to return to 0.154.0; this is an observation from 0.157.1 before that rollback, not a claim that rollback has already fixed this run.

While only reading three project Markdown files in the same Windows workspace, three read-only tool requests failed before their target commands started:

rg --files to locate Project_Architecture.md, File_Structure.md, and Development_Log.md: failed in about 0.8 s, before listing files.
Three parallel PowerShell reads with explicit UTF-8 (two complete files and the last 100 lines of the log): the unified process-creation layer rejected the request in about 0.4 s; no file contents were returned. This result does not isolate any one document or subcommand.
An independent Get-Content -LiteralPath 'Development_Log.md' -Encoding UTF8 | Select-Object -Last 100: failed in about 0.3 s, also before the read started.

The common error was:

exec_command failed: CreateProcess { message: "Rejected(\"Failed to create unified exec process: helper_unknown_error: setup refresh had errors\")" }

Subsequent PowerShell path checks confirmed that all three files existed (11,523, 4,998, and initially 94,368 bytes respectively). Individual reads of the first two succeeded. Repeating the log-tail pipeline inside a PowerShell script block (& { ... }) succeeded in about 0.2 s. This establishes that the documents were readable; it does not establish that the script block fixes sandbox setup. No write, build, or hardware operation was involved in these failures.

Unlike the earlier 0.156.0 case, I do not have a matching low-level sandbox-refresh log for these three 0.157.1 failures. Therefore I cannot confirm whether the same 291-character CUA Node runtime cache path triggered them. The shared setup refresh had errors symptom persists across these versions, whereas the 0.154.0 controlled read-only test previously completed 12/12 commands and 13/13 refreshes successfully.

A separate startup message on 0.157.1 when launching codex.cmd from an administrator terminal requested a non-elevated terminal or --no-daemon; that daemon privilege guard occurs before this sandbox command-start failure and is not being presented as its root cause.

For those experiencing this issue, here is a potential workaround:

If your Codex logs look similar to:

runtime read/execute validation failed: validate runtime read/execute access on <LOCALAPPDATA>\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_modules\...

Going to the cua_node folder and moving those subfolders out (or deleting them) should temporarily fix the problem.

This may cause side effects. In my case, the sandbox kept restarting every time Codex executed a command (not sure if this is just on my end). Use with caution.

I can confirm what appears to be the same regression on Windows, with a strong same-machine A/B reproduction.
Environment

Windows 11 x64
Codex Desktop package: OpenAI.Codex_26.1002.6548.0_x64
Current/bundled CLI: codex-cli 0.162.0-alpha.2
Windows sandbox: elevated
Auth: ChatGPT account
Failure on 0.162.0-alpha.2
Ordinary managed local execution fails before the requested command process is created:
Failed to create unified exec process:
helper_unknown_error: setup refresh had errors

The correlated sandbox log repeatedly shows:
runtime read/execute validation failed
open ACL target for root-only update:
The process cannot access the file because it is being used by another process. (os error 32)

The failing target is inside Codex's own CUA runtime:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node<runtime>\

Initially the failure was on:
bin\node_repl.exe

After disabling node_repl, the same failure moved to:
bin\node_modules@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll

This makes it look like a runtime-tree ACL validation / sharing-violation issue rather than one damaged runtime file.
Troubleshooting already performed

Full Windows reboot
Completely closed Codex Desktop and confirmed runtime image hosts = 0
Official elevated sandbox reprovision succeeded
Rebuilt the affected cua_node runtime from the official installed package
Disabled node_repl
Reproduced from a maintenance workspace outside the development tree
Confirmed project filesystem, hashes, Git repositories, worktrees, and NTFS Junction integrity separately
None of the above restored ordinary managed execution on 0.162.
Strong A/B result
On the same Windows machine, same user account, same maintenance workspace:
codex-cli 0.154.0
model: gpt-5.6-sol
sandbox: workspace-write

successfully spawned PowerShell:
powershell.exe ...
succeeded

C:\RF-Maintenance\RF-DEV-SSD-MIGRATION-001

No helper_unknown_error, no setup-refresh failure, and no os error 32.
So the observed behavior is:
0.162.0-alpha.2 -> Windows managed sandbox fails before command spawn
0.154.0 -> managed sandbox successfully spawns PowerShell

A standalone current CLI using danger-full-access also executes normally, which further suggests that the project data, shell, and filesystem are healthy and that the failure is isolated to the managed Windows sandbox path.
One additional complication: downgrading to 0.154 is not a viable long-term workaround for my workflow because I need GPT-6.1 Sol, and the older CLI returns:
The 'gpt-6.1-sol' model is not supported when using Codex with a ChatGPT account.

Is this confirmed to be the same post-0.154 Windows sandbox regression? If so, is there a fixed CLI/Desktop build available or a supported workaround that preserves the current model support and managed sandboxing?
I can provide the correlated sandbox.*.log excerpts, ProcMon data, runtime ACL details, and exact reproduction timestamps if useful.

Follow-up with controlled Windows 10 Desktop tests, cross-referencing #51668 (rollback/version behavior) and #41073 (community-reported controlled-update workaround).

Environment

Windows 10 Pro 2004, build 19041, x64.
Codex Desktop MSIX package 26.1002.7124.0: previously reproduced Windows elevated-sandbox failures, including helper_unknown_error: setup refresh had errors and runtime ACL validation / sharing violation (os error 32) under the application's cua_node runtime tree.
Rollback package 26.930.7945.0: installed in-place via Add-AppxPackage -ForceUpdateFromAnyVersion (no uninstall); existing project/chat history retained.

Update/reboot observations

With only the Microsoft Store UI automatic-app-updates toggle disabled, restarting Codex Desktop alone left the rollback package registered, but a Windows reboot resulted in 26.1002.7124.0 being registered again.
I then set user-scope CODEX_SPARKLE_ENABLED=false and machine-wide Store policy HKLM\SOFTWARE\Policies\Microsoft\WindowsStore\AutoDownload=2, following the controlled-update approach discussed in [Windows][26.820.9563.0] ChatGPT launches headless with MainWindowHandle=0; disabling updater fixes startup #41073. After a second in-place rollback to 26.930.7945.0, the next Windows reboot retained that version (Get-AppxPackage reported Status: Ok).
This is only one successful reboot with both controls applied; I did not isolate their individual effects, and it does not prove a permanent update block or identify the updater that caused the earlier replacement. The Store policy affects other Store apps.

Tool-level A/B tests after the successful reboot

In an existing project conversation, exec_command could create/read/delete a temporary file, but one apply_patch attempt returned Failed to write file.
apply_patch create/read/delete subsequently passed in an isolation workspace and in three other existing projects (including another project under the same parent drive directory).
A new diagnostic conversation targeting the exact same project root as the failing conversation loaded the same governance files read-only and successfully created/read/deleted a probe through apply_patch.
Retesting the original conversation then successfully created the probe using apply_patch. Its next verification step stopped because a strict PowerShell Get-Content -Raw comparison included a trailing newline; after normalizing only terminal CR/LF during the read-only comparison, apply_patch also successfully deleted that probe. No project/governance files were changed.

Interpretation

These tests show that apply_patch is not universally broken, and the original conversation's write failure was not consistently reproducible. Conversation/session execution state or a transient sandbox condition remains a possibility; root cause is not established.
The rollback plus controlled updates is an environment-stabilization workaround, not a verified sandbox fix. We have not confirmed whether any currently released package fixes the underlying Windows sandbox issue.
I did not delete active cua_node runtimes or change project ACLs as part of these final tests.

Sharing the A/B details in case they help distinguish session-specific apply_patch failures from the runtime validation failures already discussed here.

Navigation Menu

Repository navigation

[Windows] Regression in CLI 0.155.0: elevated sandbox initialization fails during runtime path validation; 0.154.0 works #46388

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Windows sandbox setup fails on a bundled runtime path longer than MAX_PATH despite LongPathsEnabled=1

Impact

Environment

Actual behavior

Reproduction observed on the affected installation

Supporting Windows API experiment

Controlled local workaround and outcome

Requested upstream investigation

Privacy

Windows sandbox setup fails validating a long path in the bundled CUA runtime

Existing reports checked 2026-09-23

Additional verification

Impact and reproduction

Observed evidence

Suspected cause, not yet proven in the helper

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Windows] Regression in CLI 0.155.0: elevated sandbox initialization fails during runtime path validation; 0.154.0 works #46388

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Sep 18, 2026

84dnnvbdvp-debug commented on Sep 18, 2026

sjtequiniti commented on Sep 19, 2026

shteren1 commented on Sep 19, 2026

mhscott64 commented on Sep 20, 2026

vance-gk commented on Sep 20, 2026

Windows sandbox setup fails on a bundled runtime path longer than MAX_PATH despite LongPathsEnabled=1

Impact

Environment

Actual behavior

Reproduction observed on the affected installation

Supporting Windows API experiment

Controlled local workaround and outcome

Requested upstream investigation

Privacy

brandstaetter commented on Sep 20, 2026

laulguo commented on Sep 22, 2026

hararly-web commented on Sep 23, 2026

hararly-web commented on Sep 23, 2026

BlackVS commented on Sep 23, 2026

Windows sandbox setup fails validating a long path in the bundled CUA runtime

Existing reports checked 2026-09-23

Additional verification

Impact and reproduction

Observed evidence

Suspected cause, not yet proven in the helper

professorsergiobarros commented on Sep 23, 2026

Vialythen commented on Sep 24, 2026

Freemlen commented on Sep 25, 2026

dave58914 commented on Sep 26, 2026

dave58914 commented on Sep 26, 2026

dave58914 commented on Sep 27, 2026

dave58914 commented on Sep 27, 2026

NatsunekoJF commented on Sep 27, 2026

hararly-web commented on Sep 28, 2026

CuNO3 commented on Sep 29, 2026

Hyun-Seong-su commented on Oct 7, 2026

dave58914 commented on Oct 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions