Windows Desktop sandbox fails with setup refresh failed / CreateProcessAsUserW failed

i meet the same error.

Same Here

Same here, it makes codex basically unusable. This should have high priority!

UPDATE:

I was able to get the Windows sandbox working again, but I changed a few things at once, so I cannot say which part was the actual fix.

Before it started working again, I noticed that quitting Codex Desktop completely still left a codex-windows-sandbox process running in Task Manager. I manually killed that leftover process, then started Codex again.

At the same time, my relevant config now has:

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

[windows]
sandbox = "unelevated"

[features]
elevated_windows_sandbox = false

[desktop]
runCodexInWindowsSubsystemForLinux = false

UPDATE 2:

After more testing, this is only partially fixed for me.

Normal Windows-native sandbox command execution now works again for simple/direct commands, e.g. git status, Get-Content, and direct Python commands like:

.\.venv\Scripts\python.exe -m pytest
.\.venv\Scripts\python.exe -m mypy src

However, I still see sandbox-related permission/process issues in some cases:

1. bun run fmt still fails inside Codex with:

oxfmt: spawn EPERM

The same command works in my normal PowerShell terminal. So direct process execution seems fixed, but nested process spawning (bun -> oxfmt) still appears blocked or mishandled.

1. uv run pytest / uv run mypy src failed inside Codex because uv could not access or create cache files:

Failed to initialize cache ... Access is denied. (os error 5)

1. Git ref mutations can still fail from Codex. For example, creating a branch failed because Git could not create a lock file under .git/refs/heads/...:

Unable to create ... .lock: Permission denied

Inspecting ACLs showed explicit Deny Write/Delete rules on parts of .git, so the sandbox can read the repo and edit workspace files, but some Git metadata writes are blocked.

So the original CreateProcessAsUserW failed: 1312 problem seems improved after killing the leftover codex-windows-sandbox process / changing config / restarting, but the Windows sandbox still has narrower permission issues around child process spawning, tool caches, and .git ref writes.

The relevant config I’m currently using is still as above.

Normal PowerShell outside Codex can run all of the failing commands successfully.

Same Here

UPDATE 1

switch to unelevated sandbox can solve this problem but codex probably can read all the document in your computer.So it's better to edit the Personalization to limit the model.

Adding another reproduction report for the native Windows sandbox process launch failure.

Environment

• Component: Codex CLI
• Version: codex-cli 0.134.0
• Platform: Windows / native PowerShell
• Install path after fix: npm global package under %APPDATA%\npm
• Config used:

approval_policy = "on-request"
sandbox_mode = "workspace-write"
web_search = "cached"

[windows]
sandbox = "elevated"
sandbox_private_desktop = true

Original install issue

The Microsoft Store / app install resolved first in PATH:

C:\Users\<USER>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

codex --version returned:

codex-cli 0.134.0

but the sandbox setup helper was missing:

where.exe codex-windows-sandbox-setup.exe
# INFO: Could not find files for the given pattern(s).

Installing @openai/codex@latest through npm provided both helpers:

...\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe
...\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\codex-resources\codex-command-runner.exe

After uninstalling the Store app and removing the stale PATH entry, codex resolves only to npm:

C:\Users\<USER>\AppData\Roaming\npm\codex.cmd
C:\Users\<USER>\AppData\Roaming\npm\codex

Current sandbox failure

From an elevated PowerShell prompt:

mkdir "$env:USERPROFILE\code\codex-sandbox-test" -Force
cd "$env:USERPROFILE\code\codex-sandbox-test"
codex sandbox windows cmd /c echo CODEX_SANDBOX_OK

Result:

windows sandbox failed: CreateProcessWithLogonW failed: 267

Then from a root-level test folder:

cd C:\
New-Item -ItemType Directory -Force C:\codex-test | Out-Null
cd C:\codex-test
codex sandbox windows -- cmd /d /c "echo CODEX_SANDBOX_OK && cd"

Result:

windows sandbox failed: runner error: CreateProcessAsUserW failed: 2

Using a full path to cmd.exe gives the same error:

codex sandbox windows -- C:\Windows\System32\cmd.exe /d /c "echo CODEX_SANDBOX_OK && cd"

Result:

windows sandbox failed: runner error: CreateProcessAsUserW failed: 2

Notes

• This appears to progress past the missing-helper problem after switching from the Store app to npm.
• The remaining failure looks like the native Windows elevated sandbox is failing at sandboxed process launch, not command PATH resolution.
• No danger-full-access / YOLO mode was used.
• The user wants to use Codex CLI safely with native Windows sandboxing rather than falling back to full access.

Uninstalling the WindowsApps/MSIX version of PowerShell and reinstalling the MSI version fixed the 'CreateProcessAsUserW failed: 1312' issue for me.

Uninstalling the WindowsApps/MSIX version of PowerShell and reinstalling the MSI version fixed the 'CreateProcessAsUserW failed: 1312' issue for me.

switch to unelevated sandbox can solve this problem but codex probably can read all the document in your computer.So it's better to edit the Personalization to limit the model.

+1

Tool use is broken on Windows with this setup, codex can not do practically anything without approval.

Uninstalling the WindowsApps/MSIX version of PowerShell and reinstalling the MSI version fixed the 'CreateProcessAsUserW failed: 1312' issue for me.

It worked for me. I used following command to install it:

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

Adding a more detailed reproduction for the CreateProcessAsUserW failed: 1312 case where the default shell resolves to PowerShell installed as MSIX/AppX.

Environment

• Windows 11
• Codex Desktop package: OpenAI.Codex_26.611.8273.0_x64__2p2nqsd0c76g0
• Sandbox runner: codex-command-runner-0.140.0-alpha.19.exe
• Windows sandbox mode: elevated
• Original shell: PowerShell 7 MSIX/AppX package Microsoft.PowerShell_7.6.3.0_x64__8wekyb3d8bbwe
• Sandbox user: Codex-managed offline sandbox user

Symptom

Ordinary Codex tool calls failed before the requested command started:

windows sandbox: runner error: CreateProcessAsUserW failed: 1312

The Codex sandbox log showed the default shell being launched through the App Execution Alias:

%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe -NoProfile -Command ...

Windows Event Log corroborated it as an AppModel/AppX activation failure:

Provider: Microsoft-Windows-AppModel-Runtime
Event ID: 202
Error: 0x80070520
Message: Cannot create the process for package Microsoft.PowerShell_7.6.3.0_x64__8wekyb3d8bbwe because an error was encountered. [FinishPackageActivation]

0x80070520 maps to Win32 error 1312 / ERROR_NO_SUCH_LOGON_SESSION.

A/B test in the same Codex sandbox

These worked:

codex.exe sandbox -- "%WINDIR%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -Command "whoami; $PSVersionTable.PSVersion"
codex.exe sandbox -- "%WINDIR%\System32\cmd.exe" /c "whoami && ver"

These failed with CreateProcessAsUserW failed: 1312:

codex.exe sandbox -- "%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe" -NoProfile -Command "whoami; $PSVersionTable.PSVersion"
codex.exe sandbox -- "C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.3.0_x64__8wekyb3d8bbwe\pwsh.exe" -NoProfile -Command "whoami; $PSVersionTable.PSVersion"

That suggests the sandbox user/token was not globally broken: WinPS 5.1 and cmd.exe launched successfully, but the MSIX/AppX PowerShell activation path failed under the sandbox user.

Additional checks

• The app resources runner, local Codex bin runner, and copied sandbox runner had matching SHA-256 hashes.
• Authenticode signature status was valid.
• The copied runner ACL granted the Codex sandbox users group read/execute.
• The sandbox account existed, was enabled, had its profile loaded, and could run WinPS 5.1 / cmd.exe.

Workaround that fixed it

Uninstalling the MSIX/AppX PowerShell package and installing the MSI/Win32 PowerShell 7 package fixed ordinary Codex tool calls. After the fix:

where.exe pwsh
<install-dir>\PowerShell\7\pwsh.exe

A normal Codex tool shell test succeeded with:

PowerShell 7.6.3
sandbox user
utf-8 output encoding

Request

It may be useful for Codex on Windows to detect when the default shell resolves to an MSIX/AppX App Execution Alias (%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe) and either prefer a regular Win32 shell executable, emit a clearer diagnostic, or document MSI/Win32 PowerShell 7 as the safer option for native Windows sandbox shell execution.

This issue exists on v26.5616.41845 (Released on 3/6/2025)

Terrible Strange thing!!!
Created a new chat, and everything working again.

Workaround / Root-cause analysis

I hit a similar setup refresh failed error, but with a slightly different root cause than the H: drive SetNamedSecurityInfoW error reported above. Sharing in case it helps narrow the issue.
My scenario
Every time apply_patch starts, Codex refreshes the ACLs on its three writable roots. On my machine, the refresh fails because C:\tmp returns Windows error 5 (ERROR_ACCESS_DENIED) during the write-ACE update, causing the entire refresh to abort. The project directory itself is fine.
Root cause
C:\tmp is owned by BUILTIN\Administrators. Codex (running as my standard user) cannot update the ACL on that directory, so the sandbox setup bails out.
Minimal fix
No file content needs to change. I only had to change the owner of C:\tmp to my current user or make current user has inheritable _FullControl_ permission on C:\tmp.
After that, Codex was able to add the required ACEs on its own and the sandbox initialized successfully.

Suggestion for the Codex team

It might be worth handling ownership-related ERROR_ACCESS_DENIED more gracefully—either by skipping non-project roots that can't be modified, or by surfacing a clearer error message so users don't have to dig through sandbox.log to find which directory is blocking setup.

Hope this helps anyone else stuck on the same setup refresh failed loop.

Adding another confirmed reproduction and successful workaround, this time on a current Windows 11 Insider Beta system and current Codex versions.

Environment

• Windows 11 Insider Beta, build 29617.1000, x64
• Codex Desktop: 26.707.3748.0
• Codex CLI: 0.144.1
• Windows sandbox: elevated
• PowerShell: 7.6.3
• Original PowerShell package: MSIX/AppX Microsoft.PowerShell_7.6.3.0_x64__8wekyb3d8bbwe

The failure persisted after fully rebooting Windows. Ordinary sandbox shell calls failed before the command started:

CreateProcessAsUserW failed: 1312

The selected shell was the App Execution Alias / WindowsApps package:

%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe
C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.3.0_x64__8wekyb3d8bbwe\pwsh.exe

At the matching timestamps, Microsoft-Windows-AppModel-Runtime/Admin contained Event ID 202:

0x80070520
[FinishPackageActivation]

This maps to Win32 error 1312 / ERROR_NO_SUCH_LOGON_SESSION. The sandbox accounts existed and were enabled, so this was not fixed by refreshing credentials or rebooting.

Workaround used

We kept the elevated native Windows sandbox configuration unchanged. We did not switch to unelevated, danger-full-access, or WSL.

We replaced PowerShell 7 MSIX with the official MSI/WiX package:

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

Important practical note: do not let the MSIX pwsh.exe being removed host both commands. In our first attempt, uninstalling MSIX terminated the current shell/stdout before the install command ran. We recovered by launching the install from the built-in Windows PowerShell 5.1 executable:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Running the uninstall and install as separate steps from Windows PowerShell 5.1 (or another unaffected host) avoids that self-uninstall problem.

Result after fully restarting Codex Desktop

PSHOME: C:\Program Files\PowerShell\7
PowerShell: 7.6.3
where pwsh: C:\Program Files\PowerShell\7\pwsh.exe
sandbox identity: CodexSandboxOffline account

Post-fix validation succeeded:

• normal sandbox shell execution
• project test command: 6/6 tests passed
• apply_patch create/delete probe
• image-reading tool
• clean Git working tree

So on this machine the sandbox token itself was healthy; the failure was specifically the MSIX/AppX PowerShell activation path. Replacing it with the MSI/Win32 build resolved error 1312 without weakening the sandbox policy.