Windows sandbox: command execution fails with `CreateProcessWithLogonW failed: 5`

Exactly same issue on VS code extension!! Impossible to work!

### What version of Codex is running? codex-cli 0.80.0 ### What subscription do you have? ChatGPT Plus ### Which model were you using? gpt-5.2 (reasoning medium, summaries auto) ### What platform is your computer? Microsoft Windows NT 10.0.17763.0 x64 ### What issue are you seeing? After upgrading to Codex CLI v0.80.0 on native Windows, agent mode started prompting for approval for almost every command, including simple read-only commands inside the workspace (for example cmd.exe /c type AGENTS.md). In addition, command execution inside the Windows sandbox fails with: windows sandbox: CreateProcessWithLogonW failed: 5 This prevents apply_patch and even basic commands from running. The behavior persisted even after downgrading to v0.79.0, until I forced a sandbox re-onboarding flow (disable experimental_windows_sandbox, restart, then accept the “Enable experimental sandbox” onboarding prompt). After that re-onboarding, sandbox execution worked again and the patch could be applied. Also, release notes mention /elevate-sandbox, but the command is not recognized and is not present in the slash command list in my TUI session. Finally, approval mode appears inconsistent during onboarding: /status showed Approval: on-request even though config.toml had approval_policy = "on-failure". After codex resume, /status returned to on-failure. ### What steps can reproduce the bug? Repro (high level) 1. Install/run Codex CLI v0.80.0 on native Windows (no WSL). 2. Ensure agent mode is enabled and sandbox is workspace-write. 3. Run any prompt that needs to read files and apply a patch. 4. Observe repeated approval prompts for in-workspace commands and/or failures: windows sandbox: CreateProcessWithLogonW failed: 5 Notes Even after downgrading to v0.79.0 the failure persisted, until the sandbox was re-onboarded via the UI prompt. Workaround that recovers the sandbox 1. Set experimental_windows_sandbox = false in ~\.codex\config.toml and restart Codex. 2. Accept the “Enable experimental sandbox” onboarding prompt. 3. After this re-onboarding, sandbox process creation works again and apply_patch succeeds. Uploaded thread: 019baafa-08a3-72b0-8595-7588471ad5d1 ### What is the expected behavior? Expected behavior On native Windows, with sandbox workspace-write, Codex should be able to run read-only commands inside the workspace without per-command approvals (unless accessing outside workspace or network). approval_policy should be consistently reflected by /status, and should follow config.toml unless explicitly overridden. Windows sandbox should be able to create processes reliably, so apply_patch and basic commands do not fail with CreateProcessWithLogonW failed: 5. ### Additional information Environment OS: Windows 10 Enterprise LTSC 2019 (1809), build 17763.7792 (native, no WSL) Codex CLI: v0.80.0 (problem), v0.79.0 (problem persisted after downgrade) Install: npm global (@openai/codex) Shell: Windows PowerShell 5.1 and cmd.exe Workspace: D:\Downloads\LTSC clean\win10-ltsc-2021-clean-quiet-baseline Config (~\.codex\config.toml): sandbox_mode = "workspace-write" approval_policy = "on-failure" [features] experimental_windows_sandbox = true * [features] elevated_windows_sandbox = false (also tested true/false) <img alt="Image" width="1401" height="659" src="https://private-user-images.githubusercontent.com/226635167/534399756-ab72f0fe-9dab-4107-8107-4ee00f32ba30.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjgxODUyMDEsIm5iZiI6MTc2ODE4NDkwMSwicGF0aCI6Ii8yMjY2MzUxNjcvNTM0Mzk5NzU2LWFiNzJmMGZlLTlkYWItNDEwNy04MTA3LTRlZTAwZjMyYmEzMC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMTEyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDExMlQwMjI4MjFaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT02OWUzMmFiOGE5YTNjOWNmNWU5MTFmZTg4YTMyYTYyZTI0ZjNhYjUxNzgxZjA5OWEyNzVmODNhY2I4ODY4MmRhJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.T8fPSjh8FAyH1BMF1FefB3RpT_SujN-jNfSJeMPpl_4"> <img alt="Image" width="1919" height="740" src="https://private-user-images.githubusercontent.com/226635167/534399772-fa6cde0e-b235-4485-a837-c9e7f74586e1.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjgxODUyMDEsIm5iZiI6MTc2ODE4NDkwMSwicGF0aCI6Ii8yMjY2MzUxNjcvNTM0Mzk5NzcyLWZhNmNkZTBlLWIyMzUtNDQ4NS1hODM3LWM5ZTdmNzQ1ODZlMS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMTEyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDExMlQwMjI4MjFaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1hNTdhMjA2NWJkZThkNTZlMDAwNmJmN2YyYmNlYjU4NGI3MDI1NTU0OWIwYThiYTAyNTBjNTJhNmI2YTdmNmRmJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.UZkz-AenOdZbnoT58RtJF54sPh1ycSWOKm0aMNSRQ6Y"> <img alt="Image" width="947" height="200" src="https://private-user-images.githubusercontent.com/226635167/534399780-f5d32cdd-9e2a-4327-b903-5eadc5ccc379.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjgxODUyMDEsIm5iZiI6MTc2ODE4NDkwMSwicGF0aCI6Ii8yMjY2MzUxNjcvNTM0Mzk5NzgwLWY1ZDMyY2RkLTllMmEtNDMyNy1iOTAzLTVlYWRjNWNjYzM3OS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMTEyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDExMlQwMjI4MjFaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1lM2RiMTZjNWJlNzM1YjFiN2EwNDA4OTBlODM3ODQ3YzA4NTU1MTk3MmQ5ZTE3YmU4MmNkZWQ5YTFiYThmMTA3JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.Oa1orroAetkepulhX7vPem3-mSuI2YMY6B45SNTO3zU"> sandbox.log

Try a totally brand new instance, it works again for me. Old threads are just looping with sandboxing issues loop with constant PowerShell syntax errors/ rechecking sandboxing thinking/bash command loop.

I got it working by forcing a sandbox re-onboarding/reset: in ~\.codex\config.toml I temporarily set experimental_windows_sandbox = false, restarted Codex, then accepted the “Enable experimental sandbox” onboarding prompt. After that, the sandbox started creating processes normally again, and the agent stopped spamming approvals (especially with approval_policy = "on-failure").

But the bug still exists, this looks like a workaround that reinitializes the sandbox state. Old threads can still get stuck in CreateProcessWithLogonW failed: 5 and go back to asking for approvals on trivial in-workspace commands.

@tagor-sian sorry to hear that - we're investigating this issue. Could you check your ~/.codex/.sandbox/sandbox.log and share any notable failure logs?

Thanks a lot! I attached the requested file (~/.codex/sandbox/sandbox.log) to the issue (“sandbox.log”). If it's not readable for any reason I'll upload it again gladly.

Important nuance: the sandbox.log does NOT contain the CreateProcessWithLogonW failed: 5 error. In my case that error only shows up in the Codex TUI/terminal output (and should be present in the uploaded /feedback thread artifacts for this session).

What sandbox.log contains is a single repeating pattern (hundreds/thousands of repeats with different timestamps), e.g.:

[2026-01-11 20:46:55.225 codex.exe] AUDIT: world-writable scan FAILED; cwd="D:\Downloads\LTSC clean\win10-ltsc-2021-clean-quiet-baseline"; checked=289; duration_ms=12; flagged:

• \\?\C:\Users\Public
• \\?\C:\Users\Public\AccountPictures
• \\?\C:\Users\Public\Documents
• \\?\C:\Users\Public\Downloads
• \\?\C:\Users\Public\Libraries
• \\?\C:\Users\Public\Music
• \\?\C:\Users\Public\Pictures
• \\?\C:\Users\Public\Thunder Network
• \\?\C:\Users\Public\Videos

If you want, tell me which additional log/source is best for capturing the CreateProcessWithLogonW failed: 5 error (Codex CLI main log, a specific diagnostics command output, or an excerpt from the uploaded thread), and I’ll provide it.

Uploaded /feedback thread id: 019baafa-08a3-72b0-8595-7588471ad5d1

FYI the failure persisted even after downgrading v0.80 → v0.79 until I forced a sandbox re-onboarding (set experimental_windows_sandbox=false, restart, then accept “Enable experimental sandbox” prompt). After that, process creation worked again and apply_patch succeeded.

Reopening this issue until we're confident the issue has been fixed

All of my codex sessions start with "CreateProcessWithLogonW failed: 5" error, which results in the agent modifying files using powershell scripts, instead of the apply_patch functionality. It makes the edits impossible to view, and requires approval for each file modification.

I've checked the user/.codex/.sandbox/sandbox.log file, and I can see 2 errors there:

[2026-01-20T11:46:56.604656500+00:00] ensuring sandbox users offline=CodexSandboxOffline online=CodexSandboxOnline

[2026-01-20T11:46:57.063973600+00:00] firewall rule configured name=codex_sandbox_offline_block_outbound protocol=256 LocalUserAuthorizedList=O:LSD:(A;;CC;;;S-1-5-21-1222248931-2282269676-1019675704-1004)
[2026-01-20T11:46:57.076897400+00:00] granting write ACE to D:\Work\Code\Invarion.Services for sandbox group and capability SID
[2026-01-20T11:46:57.077205900+00:00] granting write ACE to C:\Users\cooad\AppData\Local\Temp for sandbox group and capability SID
[2026-01-20T11:46:57.108130900+00:00] read-acl-only mode: applying read ACLs
[2026-01-20T11:46:57.109707500+00:00] setup error: LookupAccountNameW failed for Users: 1332
[2026-01-20 12:46:57.110 codex-windows-sandbox-setup.exe] setup error: LookupAccountNameW failed for Users: 1332
[2026-01-20T11:47:09.029709400+00:00] setup error: LookupAccountNameW failed for Administrators: 1332
[2026-01-20 12:47:09.029 codex-windows-sandbox-setup.exe] setup error: LookupAccountNameW failed for Administrators: 1332

This failes because I have a polish version of Windows, and group names are localized. So for polish version of windows it's "Użytkownicy" instead of "Users", and "Administratorzy" instead of "Administrators".

I tried running

codex-windows-sandbox-setup.exe --help

to see it there are any flags I can pass in order to provide polish names to these groups, but it looks like there's no human-friendly interface there

This looks like another manifestation of the same underlying issue.

The sandbox setup is resolving Users and Administrators by localized group names instead of using well-known SIDs.

This should be fixable with a very small patch: resolve these groups by well-known SIDs, not by localized names.

For reference, the relevant well-known SIDs are:

Administrators group: S-1-5-32-544

Users group: S-1-5-32-545

These SIDs are locale-independent and work consistently across all Windows language versions.

Switching the sandbox setup to use SID-based resolution instead of hardcoded group names (Users, Administrators) should eliminate this entire class of failures on localized Windows installs and restore proper sandbox + apply_patch behavior.

@tagor-sian, thanks for the analysis. This PR applies your suggested fix.

Still reproducible on codex-cli v0.89 (native Windows). I had to roll back to v0.87 to keep working.

OS: Windows 10 Pro (10.0.19045, build 19045, x64)

This happens even for read-only commands inside the workspace. Log snippet:

"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe" -Command 'Get-Content -Path "C:/Users/Administrator/.codex/skills/question-relevant-file-paths/SKILL.md"' in E:\\vscodeProject\\AI_Helper_Suite
2026-01-24T01:34:36.251843Z ERROR codex_core::exec: exec error: windows sandbox: CreateProcessWithLogonW failed: 5
 exited -1 in 0ms:
execution error: Io(Custom { kind: Other, error: "windows sandbox: CreateProcessWithLogonW failed: 5" })

using codexexec

0.88 fixed the issues on the 2 machines that I work on. One is running Windows 11 Home, the other one Windows 11 Pro

I'm not sure if my error goes to same direction, maybe in my case it's the working directorie?
Codex 0.97.0

Get-ChildItem -Force
[2026-02-06 13:09:20.728 codex.exe] setup refresh: spawning C:\Users\Rene\AppData\Roaming\npm\node_modules\@openai\codex\vendor\x86_64-pc-windows-msvc\codex\codex-windows-sandbox-setup.exe (cwd=Z:\Software\_CODEX\_temp_task, payload_len=756)
[2026-02-06T12:09:20.770548200+00:00] granting write ACE to \\?\UNC\192.168.178.58\Freigabe\Software\_CODEX\_temp_task for sandbox group and capability SID
[2026-02-06T12:09:20.772599200+00:00] read-acl-only mode: applying read ACLs
[2026-02-06T12:09:20.774486600+00:00] read ACL run completed
[2026-02-06T12:09:20.802499700+00:00] setup refresh: processed 2 write roots (read roots delegated); errors=[]
[2026-02-06 13:09:20.803 codex-windows-sandbox-setup.exe] setup binary completed

This is still happening for me with a fresh install of codex-cli 0.101.0.

The error I get is: windows sandbox: CreateProcessWithLogonW failed: 2

The error I get is: windows sandbox: CreateProcessWithLogonW failed: 2

I see this in v0.114.0

Still having a similar issue on Codex App 0.115.0-alpha.4.

I have an automation running that triggers a skill. The app is set to having 'Full Access'.
Every time the automation runs I get windows sandbox: CreateProcessWithLogonW failed: 1326

Love the idea of automations. but this error kinda kills the purpouse of them.

I just had an exactly same issue in the latest version of codex.

Quick fix : Reinstall Codex App

@nicolasdemol Didn't work for me. I had to remove my .codex directory and re-initiate the app.

I had the exact issue in the laest version of codex at that time (0.123). But codex cli fixed itself for me. Here is the report:

Here is the concise report for OpenAI:

---

Codex native Windows sandbox failed with:

windows sandbox: runner error: CreateProcessAsUserW failed: 5

The failure was reproducible when windows.sandbox = "elevated" and the active shell resolved to the Microsoft Store / WindowsApps version of PowerShell:

C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.1.0_x64__8wekyb3d8bbwe\pwsh.exe
C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

Sandbox setup itself was not always the failing step. In the later reproduction, logs showed:

setup refresh: spawning ...\@openai\codex-win32-x64\...\codex-windows-sandbox-setup.exe
read ACL run completed
runner launch: exe=...\codex-command-runner.exe ...

But the command still failed before codex-command-runner.exe logged runner start, with:

CreateProcessAsUserW failed: 5

This suggests the elevated sandbox runner could start, but failed when trying to launch the Store/WindowsApps pwsh.exe inside the sandboxed user context.

Installing the MSI version of PowerShell fixed the issue. After installing MSI PowerShell, pwsh resolved to the normal install path instead of WindowsApps:

C:\Program Files\PowerShell\7\pwsh.exe

After that, Codex elevated Windows sandbox commands worked.

Likely root cause: Codex elevated sandbox has a compatibility issue when the configured shell is the WindowsApps / Store packaged pwsh.exe. The packaged PowerShell has AppX/WindowsApps ACL and package identity constraints that do not work correctly with Codex’s elevated sandbox user / CreateProcessAsUserW launch path.

Recommended improvement: detect when pwsh resolves to WindowsApps and either warn clearly, automatically prefer a non-Store PowerShell installation if available, or fall back to powershell.exe with an actionable diagnostic.

I just changed the sandbox = "elevated" to sandbox = "unelevated" then fixed. what's the different?

@ruiheng I can confirm that this workaround fixed the issue in my environment.

My setup was using the Microsoft Store / MSIX version of PowerShell, and sandboxed commands were failing with:

windows sandbox: runner error: CreateProcessAsUserW failed: 1920

After uninstalling the Microsoft Store / MSIX version, I installed the MSI/WiX version of PowerShell with:

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

After that, Codex was able to run the same sandboxed commands successfully without requiring escalation.

Verified commands included simple Get-Content, Get-ChildItem, git status --short, and a Node-based validation command. All worked normally after switching to the MSI-installed PowerShell.

Thanks for the pointer!

@YdayangY either.
Based the official website. Elevated is been suggested. But i cannot get what the different between them based on the https://developers.openai.com/codex/config-basic
Have you got any idaes?

Any progress?

Any progress?

This issue was resolved a long time ago. In what form is it appearing for you now? And in which version of Codex?

Also reproducing in Codex App 26.707.9981.0 on Microsoft Windows NT 10.0.26100.0 x64. The safe apply_patch helper repeatedly fails with CreateProcessWithLogonW failed: 5, including inside a permitted workspace. Read-only operations and separately approved elevated commands work. The failure persists across Codex restarts and tasks.
Feedback ID: 019f4ff5-7668-7e42-ad5f-e7b370fd9297

Tested the documented unelevated sandbox fallback in Codex App 26.707.9981.0 on Microsoft Windows NT 10.0.26100.0 x64. Creating a new file with apply_patch succeeded, but ordinary sandboxed command execution and apply_patch updates to existing files still failed with CreateProcessWithLogonW failed: 5. Restored sandbox = "elevated" afterward. Feedback ID: 019f4ff5-7668-7e42-ad5f-e7b370fd9297

Confirmed on current Codex Desktop for Windows.

Environment

• Codex Desktop: 26.715.4045.0
• Codex CLI/runtime reported by codex doctor: 0.145.0-alpha.18
• OS: Windows 10 Pro 10.0.19045 x64
• Plan: ChatGPT Plus
• Native Windows local workspace (not WSL)

Repro

With this configuration:

sandbox_mode = "workspace-write"

[windows]
sandbox = "elevated"

every sandboxed command fails before the requested process starts, including apply_patch and trivial read-only commands:

windows sandbox: CreateProcessWithLogonW failed: 5

The failure is independent of the project folder. I verified that:

• the workspace is writable;
• target files are not read-only;
• CodexSandboxOffline and CodexSandboxOnline exist, are enabled, and have PasswordExpired = 0;
• the sandbox group has the expected workspace permissions.

The older sandbox re-onboarding workaround was not sufficient in my Desktop setup.

Working workaround

Changing only this setting fixes the issue:

[windows]
sandbox = "unelevated"

After starting a fresh Codex process, I confirmed that it could successfully:

1. run PowerShell commands inside the workspace;
2. use apply_patch to modify a file;
3. run git diff to verify the change.

This looks closely related to the current elevated-vs-unelevated Windows sandbox failure family, including #24098.

Additional diagnostic

codex doctor --json reports the installation/config as healthy, but update/runtime download checks also fail on this machine with:

curl: (35) schannel: next InitializeSecurityContext failed:
CRYPT_E_NO_REVOCATION_CHECK (0x80092012)

That may be a separate Windows TLS/revocation issue, but the elevated sandbox failure is reproducible even though the sandbox accounts and workspace ACLs are healthy.

Feedback/thread ID: 019f75c0-8d55-7863-a9e1-89189ccd69e1

Try a totally brand new instance, it works again for me. Old threads are just looping with sandboxing issues loop with constant PowerShell syntax errors/ rechecking sandboxing thinking/bash command loop.

This sadly seems to only work temporarely. After a few prompts it bugs out again.
sandbox = "unelevated" does the trick, but I don't like it (I assume it's less secure?)