[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:

1. Install Codex CLI 0.155.0:

   npm install -g @openai/codex@0.155.0
   

2. Use the following configuration:

   sandbox_mode = "workspace-write"
   approval_policy = "on-request"
   
   [windows]
   sandbox = "elevated"
   

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

4. Observe that sandbox initialization fails with:

   helper_unknown_error: setup refresh had errors
   

5. Exit Codex and downgrade:

   npm install -g @openai/codex@0.154.0
   

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

Reproduce the failure with CLI 0.155.0 on Windows using elevated sandbox mode, workspace-write, and the reported long runtime-cache path; compare the result with 0.154.0. Start by tracing elevated sandbox initialization and runtime read/execute validation, then confirm completion when sandboxed commands and workspace file operations work on the affected setup without requiring a downgrade.