Windows Desktop 26.715.31925: elevated sandbox cannot start shell; unelevated starts but has write/arg0 failures

What version of the Codex App are you using?

26.715.31925

What subscription do you have?

ChatGPT subscription (exact tier omitted)

What platform is your computer?

Windows, Microsoft Windows NT 10.0.26200.0

Summary

On Codex Desktop 26.715.31925, the elevated Windows sandbox was unable to start shell commands at all. Switching only the Windows sandbox implementation to unelevated restored basic PowerShell execution.

However, the unelevated path is still only partially functional:

• basic PowerShell commands, pipelines, subprocess launch, workspace reads, and DNS work;
• filesystem writes to the advertised writable workspace root fail with Access is denied;
• outbound HTTPS from the sandbox fails through Schannel;
• nonzero child exit codes are not preserved exactly by the shell helper;
• both the PATH CLI and Desktop-configured CLI warn that stale arg0 directories cannot be cleaned and PATH aliases cannot be created due to access denial.

This appears related to the recurring elevated Windows sandbox/helper regression reported in #24098, #24259, #24490, #24963, and #25280.

Runtime versions

Two different Codex binaries are present:

PATH CLI:
codex-cli 0.144.6

Desktop-configured internal CLI:
codex-cli 0.145.0-alpha.18

The internal Desktop CLI is configured under %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe.

Both binaries currently print warnings similar to:

WARNING: failed to clean up stale arg0 temp dirs: Access is denied. (os error 5)
WARNING: proceeding, even though we could not create PATH aliases: Access is denied.
path: "%USERPROFILE%\.codex\tmp\arg0\codex-arg0..."

Configuration

The configuration that currently allows basic shell startup is:

sandbox_mode = "workspace-write"

[windows]
sandbox = "unelevated"

[sandbox_workspace_write]
network_access = true

The workspace is trusted.

Before switching to unelevated, the configuration used:

[windows]
sandbox = "elevated"

In that mode, the shell helper did not reach PowerShell at all. The exact raw error from the earlier elevated session is no longer available, and no %CODEX_HOME%\.sandbox\sandbox.log file currently exists.

Steps to reproduce

1. Install or update Codex Desktop to 26.715.31925 on Windows.
2. Configure:

```toml
sandbox_mode = "workspace-write"

[windows]
sandbox = "elevated"

[sandbox_workspace_write]
network_access = true
```

1. Fully restart Codex Desktop.
2. Start a task in a trusted local workspace.
3. Ask Codex to run a minimal shell command:

``powershell
Write-Output "sandbox-ok"
``

1. Observe that the elevated sandbox/helper does not start the shell.
2. Change only:

``toml
[windows]
sandbox = "unelevated"
``

1. Fully restart Codex Desktop and repeat the command.
2. Observe that basic shell execution now succeeds.
3. Run a workspace write probe and observe Access is denied, despite workspace-write and the workspace root being advertised as writable.

Additional environment detail

TEMP and TMP point to a RAM-disk directory. Its ACL was inspected and grants Modify to Authenticated Users and FullControl to application-package groups. The same write failure also occurs on the normal local workspace drive, and the persistent arg0 warning targets %USERPROFILE%\.codex\tmp\arg0, not the RAM disk. Therefore the RAM disk may amplify temp/cache symptoms but does not explain the elevated helper being unable to start the shell.

Expected behavior

• The preferred elevated Windows sandbox should start the requested shell command.
• workspace-write should allow writes inside the declared workspace root.
• network_access = true should permit outbound HTTPS.
• The helper should create/clean its arg0 aliases or emit an actionable diagnostic identifying the ACL or sandbox identity that blocks them.
• If elevated setup is unavailable, Codex should detect and report the exact failed setup stage instead of leaving the shell unusable.

Actual behavior

• Elevated sandbox: shell does not start.
• Unelevated sandbox: basic shell execution works, but workspace writes and several helper capabilities remain broken.
• Desktop uses codex-cli 0.145.0-alpha.18 internally while the separately installed PATH CLI is 0.144.6.
• codex doctor-style configuration checks are insufficient if they do not perform a real sandboxed spawn/write probe.

Related issues

• #24098
• #24259
• #24490
• #24963
• #25280
• #31776
• #34039 (same Desktop build/internal CLI family, different runtime regression)

No project files, usernames, credentials, or private logs are included in this report.