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

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

• #33732

Powered by Codex Action

Confirming the same elevated/unelevated failure trap on a newer Codex Desktop build.

Environment

• Codex Desktop: 26.715.4045.0
• Windows 11 Home: 10.0.26200, x64
• sandbox_mode = "workspace-write"

Elevated sandbox

With:

[windows]
sandbox = "elevated"

a minimal shell command failed before PowerShell started:

Write-Output "sandbox-probe-ok"

Results:

• failed 3/3 in the workspace
• also failed with C:\tmp as the working directory
• top-level error: helper_unknown_error: setup refresh had errors
• local setup_error.json reported the same code/message
• sandbox-log classification showed read-ACE refresh failures with SetNamedSecurityInfoW failed: 87
• the identical command succeeded when explicitly run with escalation

Unelevated sandbox

I changed only the Windows sandbox implementation:

[windows]
sandbox = "unelevated"

and fully restarted Codex Desktop.

Results:

• the minimal shell command succeeded 3/3
• the same command succeeded from C:\tmp
• apply_patch could create a new probe file
• the next apply_patch update of that existing file failed with:

windows unelevated restricted-token sandbox cannot enforce split writable root sets directly; refusing to run unsandboxed

• normal sandboxed removal of the probe file returned access denied
• escalated cleanup succeeded

This matches the trap described here: elevated cannot start the shell, while unelevated restores basic shell execution but breaks normal patch/update workflows. It is also related to #34088, except the suggested workaround there (switching back to elevated) is not usable in this environment because elevated sandbox setup itself fails.

I restored sandbox = "elevated" after the test. No project data, sensitive local paths, or raw logs are included.

Corroborating evidence from a current Windows 11 x64 installation:

• Both the PATH CLI and the Desktop-configured Codex CLI repeatedly emit:

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. (os error 5)

• codex plugin list still exits 0 and lists bundled plugins as installed/enabled, so this is a real helper/cleanup failure with silent degradation rather than a complete command failure.
• Seven per-invocation USERPROFILE\.codex\tmp\arg0\codex-arg0... directories remain. Their timestamps line up with Codex process starts. The root ACL grants the user FullControl, and the lock files were readable and not exclusively locked at sampling time; the exact handle owner could not be identified without elevated handle/process inspection.
• A separate version-surface drift is present: PATH CLI codex-cli 0.144.6 versus bundled app-server codex-cli 0.146.0-alpha.3.1.

Please treat this as a lifecycle/diagnostic issue rather than a generic user-permission problem: cleanup and alias creation should either complete atomically or report the exact operation, path, process/handle, and effective authority that blocked them. No account, project, credential, or private-path data is included.

Corroborating this on a newer CLI with an isolated development-worker reproduction.

Environment

• Codex CLI: 0.147.0
• Windows: 10.0.26200.0, x64
• [windows] sandbox = "elevated"
• trusted disposable Git worktree
• explicit --sandbox workspace-write
• --ask-for-approval never --ephemeral --ignore-user-config --ignore-rules

Minimal direct reproduction

From a fresh standalone PowerShell process, with parent-task Codex permission variables removed:

$prompt | codex `
  --ask-for-approval never `
  --sandbox workspace-write `
  exec `
  --cd <DISPOSABLE_TRUSTED_WORKTREE> `
  --ephemeral `
  --ignore-user-config `
  --ignore-rules `
  --color never `
  --json `
  --output-last-message <OUTPUT_FILE> `
  -

The prompt asks Codex to create one tiny text file inside the worktree.

Observed result:

patch rejected: writing is blocked by read-only sandbox; rejected by user approval settings
Unable to create the file because the workspace is mounted read-only and approval is disabled. Nothing was modified.

A separate run with normal user config loaded reached the shell path and logged:

windows sandbox: orchestrator_helper_launch_failed:
setup refresh failed to launch helper:
helper=codex-windows-sandbox-setup.exe
error=Access is denied. (os error 5)

That run subsequently used a configured MCP filesystem tool to create the file outside the failed shell sandbox. I removed the file and do not count that as acceptance; it also demonstrates why the worker reproduction disables user config and MCP tools.

Controls and isolation

• An ordinary host process successfully wrote and removed a control file in the exact same worktree.
• Loading trusted-project/user config did not make the sandboxed shell writable.
• The same safe failure reproduced in three fresh disposable repositories/worktrees through an integration adapter on CLI 0.146.1 and 0.147.0.
• Main checkouts and branches remained untouched.
• No sandbox bypass flag was tested or used.
• WSL is not installed, so no Linux comparison was attempted.

This appears to be the same elevated Windows sandbox/helper failure rather than a Git, project-trust, ACL, OneDrive, or application-adapter problem. A portable PowerShell reproducer and JSONL evidence are retained locally.

Adding a consolidated related-issue map after a broader follow-up search. The categories below are intentional: they distinguish direct/near-duplicate behavior from adjacent symptom branches, and do not assert that every report has one proven root cause.

1. Direct / near-duplicate elevated↔unelevated Windows sandbox failures

• #33732 — bot-suggested potential duplicate; elevated sandbox hangs after ACL setup / leaks setup helpers, unelevated works (0.145.0-alpha.18).
• #24098 — elevated sandbox fails during spawn setup refresh; unelevated works.
• #24259 — intermittent setup-refresh failures despite a healthy codex doctor; host/escalated commands still work.
• #24490 — elevated setup helper fails (ShellExecuteExW ... 1223 / “parameter is incorrect”); unelevated works.
• #24963 — node_repl / browser path fails at Windows sandbox setup refresh.
• #25280 — Desktop/WSL workspace execution failure plus sandbox/helper and arg0 lifecycle symptoms.
• #31220 — Windows Desktop explicitly forces the same two-mode trap: elevated shell fails (CreateProcessAsUserW 1312), unelevated apply_patch update/delete fails on split writable roots.
• #32314 — elevated sandbox adds large per-command startup delay; unelevated restores speed but breaks apply_patch with split roots.
• #34088 — exact unelevated apply_patch failure: cannot enforce split writable root sets directly; refusing to run unsandboxed.
• #34575 — elevated sandbox loses its logon session (CreateProcessAsUserW 1312) and enters repeated retries.

2. Split writable-root / apply_patch branch

• #30009 — exact split-root refusal under unelevated; elevated path can hang instead of failing cleanly.
• #30712 — Desktop injects split writable roots, causing apply_patch to fail before reading the workspace file and pushing agents toward shell rewrites.
• #31229 — add succeeds but update/delete of existing files fails in the sandbox read/verification path.
• #32168 — runtime itself adds workspace + special temp writable roots that the unelevated backend cannot enforce.
• #32839 — view_image fails on an authorized workspace image because the same split-root sandbox construction fails before the file is read.
• #33355 — local image inputs hit the same unelevated split-root refusal; elevated mode instead hits setup-refresh failure.
• #34970 — multiple/stale writable roots break apply_patch.
• #34993 — standalone Windows CLI :workspace profile creates the same unsupported split-root shape; not Desktop-only.
• #35428 — unelevated gives the exact split-root error; elevated gives helper_unknown_error: setup refresh had errors.
• #35587 — elevated helper repeatedly reinitializes; unelevated hits the same split-root refusal.
• #35864 — root-cause analysis and bugfix proposal for the unelevated split-root rejection, with create/update/delete validation after the proposed change.

3. ACL / setup-helper / lifecycle branch

• #14585 — Windows sandbox ACL state can make repeated apply_patch fail after initially succeeding.
• #27889 — elevated setup fails while granting WindowsApps read ACLs (SetNamedSecurityInfoW failed: 5).
• #29072 — packaged codex-windows-sandbox-setup.exe launch fails from WindowsApps context.
• #29200 — repeated setup-helper modal / launch failure; codex doctor can remain green.
• #29797 — helper_unknown_error: setup refresh had errors on file reads / git log while host PowerShell works.
• #29867 — workspace ownership can be left on CodexSandboxOnline/Offline, after which setup refresh fails until ownership is repaired.
• #30732 — helper binaries exist under packaged resources but runtime lookup/launch path fails.
• #31414 — admin-owned project root causes SetNamedSecurityInfoW failed: 5; changing ownership restores operation.
• #31620 — ACL setup failure leads agents toward unsandboxed/escalated PowerShell fallback.
• #31848 — Desktop terminal fails before PowerShell starts with the same generic setup-refresh error.
• #32855 — elevated helper_unknown_error, while unelevated works.
• #33806 — injected <special>:slash_tmp → C:\tmp; inability to stamp its ACL aborts setup for an otherwise writable workspace.
• #33964 — reported regression from 0.143.x to 0.144.5 around ACL refresh / SetNamedSecurityInfoW failed: 5.
• #34000 — same Desktop build family (26.715.4045.0): create works, modifying an existing file fails through the sandbox helper.
• #33671 and #35914 — virtual-filesystem cases with SetNamedSecurityInfoW failed: 87; useful comparison for the error-87 path, though the underlying filesystem differs from the local NTFS reproduction here.

4. Schannel / network branch

The original report also notes outbound HTTPS failure under the sandbox. Closely related reports include:

• #17458 — sandbox users created without initialized Windows user profiles.
• #17459 — Schannel HTTPS fails in the Windows sandbox with SEC_E_NO_CREDENTIALS.
• #18821 — network_access = true but sandbox networking fails after ACL/setup errors.
• #31073 — Git HTTPS / Schannel credential path fails inside native Windows sandbox while host PowerShell works.
• #32088 — Desktop sandbox TLS regression; curl/Schannel fails with SEC_E_NO_CREDENTIALS while the host works.
• #21470 — broader Windows sandbox reproduction covering Schannel, child-process, WSL, and temp-write failures.

5. Usage / retry consequences

• #34575 — directly reports repeated recovery attempts after an elevated-sandbox process-spawn failure consuming nearly the entire weekly quota.
• #37613 — separate usage-credit request after repeated elevated sandbox setup refresh had errors retries and substantial token consumption.

6. Same build/runtime family, but different primary regression

• #34039 — already listed in the original report; same Desktop/internal CLI family, but a different runtime surface, so I am keeping it explicitly separated from the sandbox-root-cause group.
• #31776 — already listed in the original report; Windows apply_patch wrapper/argument path failure, adjacent but not identical to setup-refresh/split-root failure.

This issue family now spans multiple Codex/Desktop versions and several independent reporters. The strongest recurring pattern is not merely “Windows permissions”: it is a mismatch between the advertised/effective permission profile and what the selected Windows sandbox backend can actually initialize and enforce, followed by incomplete diagnostics, fallback pressure, or repeated retries.

For clarity, current backend usage/reset-credit reports such as #37934 are not included above as the same root cause. There is not yet evidence connecting that server-side 429/reset-credit behavior to this Windows sandbox family. #34575 and #37613 are the evidence-backed bridge from sandbox failure to quota/usage impact.

Temporary Aug 11 current-incident watchlist

Adding a short current-day corroboration set while reports are still arriving. This is intentionally provisional and does not assert one common root cause. I am separating the strongest Windows sandbox/execution overlaps from adjacent transport, usage, and persisted-state failures.

A. Strongest current Windows sandbox / execution overlap

• #37940 — Windows Desktop 26.803.10989.0: Windows setup loops; elevated setup does not complete; runner logs SetFileAttributesW ... Access is denied; switching to unelevated still leaves even whoami failing with Access is denied. This is a very close continuation of the “no healthy Windows sandbox mode” family documented here.
• #37919 — Windows sandbox on a Box Drive Junction: CreateProcessWithLogonW failed: 267, sandbox traversal denied, and apply_patch filesystem-helper failures while the same path works outside the sandbox. This extends the same command-start / filesystem-helper boundary to another Windows filesystem shape.
• #37965 — a Codex task leaves .git owned by CodexSandboxOffline, after which normal Git clients and Codex project detection reject the repository until ownership is repaired. This is important because it shows sandbox identity/ACL behavior can persist into user-visible repository state rather than remaining a transient command failure.
• #37932 — Windows Computer Use can fail with EPERM while touching the local OpenAI/Codex runtime path and can then enumerate zero apps/windows. Different tool surface, but another current Windows runtime/permission failure in the same desktop family.

B. Current transport / retry / incomplete-turn symptoms

• #37938 — Windows Desktop 26.803.10989.0: frequent Reconnecting 5/5, long stalls, and incomplete work; reporter explicitly notes usage being consumed during the failed/reconnecting runs.
• #37980 — Windows report filed today with stream disconnected before completion on ordinary Codex use.
• #37957 — CLI 0.147.0: WebSocket reset triggers an advertised HTTPS fallback, but the active turn still terminates instead of recovering. This is cross-platform and therefore not evidence for the Windows sandbox root cause, but it is relevant to the current failure/retry surface and incomplete-turn handling.

C. Current usage/reset visibility failures

• #37934 — /backend-api/wham/rate-limit-reset-credits returns 429 and the client repeatedly retries; reproduced in both desktop and web.
• #37951 — current CLI report: Usage limit resets — Couldn't load usage limit resets.

D. Adjacent persisted-state integrity report

• #37927 — Windows Desktop update rewrites the persisted local-projects registry from 12 entries to 0 and mirrors the same empty state into .bak, while the project roots and thread data still exist. This is not a sandbox duplicate, but it is relevant to current Windows Desktop state-integrity behavior because a derived/managed state surface becomes authoritative enough to hide valid underlying state.

For this issue, the highest-confidence new links are #37940, #37919, #37965, and #37932. The reconnect/usage/state reports above are included as contemporaneous context only. I would not merge their root causes into #34179 without stronger evidence.