Windows Desktop sandbox forces choice between CreateProcessAsUserW 1312 and apply_patch split-root failure

Open 💬 5 comments Opened Jul 6, 2026 by martinmclee

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

26.623.13972.0

Desktop package:

OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0

Codex CLI/runtime:

codex-cli 0.142.5

What subscription do you have?

Pro 5x

What platform is your computer?

Windows 11 Home 25H2, 64-bit, build 26200.8655.

Registry version fields:

ProductName        : Windows 10 Home
DisplayVersion     : 25H2
CurrentBuild       : 26200
CurrentBuildNumber : 26200
UBR                : 8655
EditionID          : Core
InstallationType   : Client

Codex environment also reported:

Microsoft Windows NT 10.0.26200.0 x64

Note: Windows compatibility APIs still report ProductName = Windows 10 Home
and NT version 10.0, but the 25H2 display version and 26200 build identify
this as a Windows 11 system.

Shell: PowerShell

What issue are you seeing?

Codex Desktop on Windows currently forces a choice between two broken sandbox
configurations:

With [windows] sandbox = "unelevated":

normal shell commands work
apply_patch can create files
apply_patch update/delete fails before patching workspace files

With [windows] sandbox = "elevated":

apply_patch create/update/delete works
normal shell commands fail before PowerShell starts

So there does not appear to be a working Windows Desktop setup where both safe
file edits and ordinary diagnostic/build/test commands work in the same session.

This looks related to both existing issues:

#30712: Desktop injects split writable roots and apply_patch cannot enforce

them under the unelevated Windows sandbox.

#30024: Windows sandbox command runner fails with

CreateProcessAsUserW failed: 1312.

Current relevant config for the latest repro:

approval_policy = "never"
sandbox_mode = "danger-full-access"

[windows]
sandbox = "elevated"

Observed with [windows] sandbox = "elevated":

windows sandbox: runner error: CreateProcessAsUserW failed: 1312

This happens even for simple read-only commands.

Observed with [windows] sandbox = "unelevated":

apply_patch verification failed: Failed to read file to update <workspace file>:
failed to prepare fs sandbox:
failed to prepare windows sandbox wrapper:
windows unelevated restricted-token sandbox cannot enforce split writable root sets directly; refusing to run unsandboxed

What steps can reproduce the bug?

Use Codex Desktop on Windows with a normal managed workspace-write session.
Set:

[windows]
sandbox = "unelevated"

Restart Codex Desktop.
In a workspace, run a normal shell command such as Get-Location.
Observe that shell commands work.
Use apply_patch to create a new file.
Observe that file creation works.
Use apply_patch to update or delete an existing workspace file.
Observe that apply_patch fails with:

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

Change config to:

[windows]
sandbox = "elevated"

Restart Codex Desktop.
Use apply_patch to create/update/delete a workspace file.
Observe that apply_patch works.
Run a simple shell command such as Get-Location, codex --version, or a

file read command.

Observe that shell execution fails before PowerShell starts with:

windows sandbox: runner error: CreateProcessAsUserW failed: 1312

What is the expected behavior?

There should be at least one Windows Desktop sandbox configuration where both of
these are true:

apply_patch can create/update/delete files inside the active workspace root.
ordinary shell commands can run for diagnostics/build/test operations.

If the unelevated Windows sandbox cannot enforce split writable root sets, Codex
Desktop should avoid injecting a sandbox shape that breaks apply_patch, or
apply_patch should use a sandbox strategy that supports the Desktop-managed
profile.

If the elevated Windows sandbox is the intended workaround for apply_patch,
ordinary shell commands should still launch successfully instead of failing with
CreateProcessAsUserW failed: 1312.

Additional information

Troubleshooting already tried without resolving the issue:

Changed [windows] sandbox to unelevated.

Result: shell commands worked, but apply_patch update/delete failed with

the split writable roots error.

Changed [windows] sandbox back to elevated.

Result: apply_patch worked, but normal shell commands failed with

CreateProcessAsUserW failed: 1312.

Restarted Codex Desktop after config changes.

Result: no change.

Ended older Codex tasks/processes and restarted Codex again.

Result: no change.

Tried launching/restarting Codex "as administrator".

Result: process token checks still reported Codex processes as not elevated

(Elevated=0), and shell commands still failed in elevated sandbox mode.

Tried:

[windows]
sandbox = "elevated"
sandbox_private_desktop = false

Result: normal shell commands still failed with

CreateProcessAsUserW failed: 1312.

Tried excluding temp writable roots:

[sandbox_workspace_write]
exclude_tmpdir_env_var = true
exclude_slash_tmp = true

Result: the Desktop managed permission profile still exposed extra writable

roots such as C:\tmp; apply_patch still failed in unelevated mode.

Tried a custom permission profile with only the workspace root writable.

Result: the config parsed and a direct codex sandbox -P <profile> ...

check worked, but Desktop managed sessions still injected the extra
writable roots, so app session behavior did not change.

Tried direct elevated launch attempts for the packaged app:

Direct Start-Process against the WindowsApps package executable failed

with access denied due to package ACLs.

Start-Process via shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App

returned success but appeared to focus/reuse the existing non-elevated app
instance instead of starting an elevated Codex process.