[Windows] apply_patch fails before patch parsing: CreateProcessAsUserW failed: 5 after WindowsApps ACL setup failure

Resolved 💬 3 comments Opened Mar 10, 2026 by kapioka Closed Mar 10, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

Codex desktop 0.112.0-alpha.3

Which model were you using?

GPT-5 family model in Codex desktop

What platform is your computer?

Windows 11 25H2 build 26200.7922 x64

What issue are you seeing?

apply_patch fails at high frequency on Windows, but the failure does not appear to be caused by patch syntax, path resolution, or file diff conflicts.

In this environment, even a minimal ASCII-only patch fails before patch parsing or file application. The failure path appears to be the internal --codex-run-as-apply-patch process launch.

Steps to reproduce

Open Codex desktop on Windows.
Use workspace-write sandbox mode.
In any trusted workspace, attempt a minimal patch such as:

*** Begin Patch
*** Add File: probe.txt
+alpha
*** End Patch
Observe that apply_patch fails even on an ASCII-only path.
Check .sandbox\\sandbox.log and .sandbox\\setup_error.json.
Expected behavior
apply_patch should either:

successfully apply the patch, or
fail with a normal patch-level error such as parse/context/path mismatch.
Actual behavior
apply_patch fails before patch parsing/application.

Observed log sequence:

ACL setup reports SetNamedSecurityInfoW failed: 5
.sandbox\\setup_error.json contains:
code: helper_unknown_error
message: read ACL run had errors
internal apply_patch launch uses:
codex.exe --codex-run-as-apply-patch
then:
runner: spawn failed: CreateProcessAsUserW failed: 5
This suggests the failure is in the Windows sandbox / packaged app child-process launch path, not in Unicode path handling.

Additional information
I initially suspected Unicode paths because the original failing workspace path contained non-ASCII characters.

However, I reproduced the same failure with a minimal ASCII-only patch, so this does not appear to be Unicode-specific.

Local diagnostics classify the issue as:

apply_patch_readiness.status = broken
root_cause = windowsapps_acl_blocks_apply_patch_spawn
likely_scope = not_unicode_specific
Relevant logs
[time] codex.exe] START: ... codex.exe --codex-run-as-apply-patch ...
[time] grant read ACE failed on C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources for sandbox_group: SetNamedSecurityInfoW failed: 5
[time] codex-command-runner.exe] runner start ... "codex.exe", "--codex-run-as-apply-patch", "*** Begin Patch ..."
[time] codex-command-runner.exe] runner: spawn failed: CreateProcessAsUserW failed: 5
[time] codex.exe] FAILURE: ... --codex-run-as-apply-patch ...
Summary
This appears to fail in the Windows sandbox child-process launch path before normal patch parsing/application.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 5 months ago

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

#13965
#13959
#14196

Powered by Codex Action

kapioka · 5 months ago

Closing as duplicate of #13965.
I added my reproduction details there, including helper_unknown_error, SetNamedSecurityInfoW failed: 5, and confirmation that the failure is reproducible with an ASCII-only patch.

artemrizhov · 20 days ago

In my case, the issue was caused by the MSIX version of PowerShell. pwsh.exe was under C:\Program Files\WindowsApps\..., and the Codex sandbox user could not start it, resulting in:

CreateProcessAsUserW failed: 5 (Access denied)

Workaround: replace the MSIX install with the MSI/WiX version. I recommend running this from cmd.exe:

winget uninstall --id Microsoft.PowerShell
winget install --id Microsoft.PowerShell --source winget --installer-type wix

This installs PowerShell to C:\Program Files\PowerShell\7\pwsh.exe. After restarting ChatGPT Codex, sandboxed commands worked normally.