Skip to content

Windows sandbox: command execution fails with CreateProcessWithLogonW failed: 5 #9062

Open
#9134
Open
Windows sandbox: command execution fails with CreateProcessWithLogonW failed: 5#9062
#9134
Labels
bugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

Description

@tagorr
tagorr
opened on Jan 11, 2026

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)

Image Image Image

sandbox.log

Activity

  1. tagorr
    added
    bugSomething isn't working
    on Jan 11, 2026
  2. github-actions
    added
    CLIIssues related to the Codex CLI
    windows-osIssues related to Codex on Windows systems
    sandboxIssues related to permissions or sandboxing
    on Jan 11, 2026

  3. openresearchtools commented on Jan 12, 2026

    @openresearchtools
    openresearchtools
    on Jan 12, 2026

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

  4. openresearchtools commented on Jan 12, 2026

    @openresearchtools
    openresearchtools
    on Jan 12, 2026

    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)

    Image Image Image
    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.

  5. tagorr commented on Jan 12, 2026

    @tagorr
    tagorr
    on Jan 12, 2026
    Author

    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.

  6. dylan-hurd-oai commented on Jan 12, 2026

    @dylan-hurd-oai
    dylan-hurd-oai
    on Jan 12, 2026
    Contributor

    @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?

  7. tagorr commented on Jan 12, 2026

    @tagorr
    tagorr
    on Jan 12, 2026
    Author

    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.

  8. dylan-hurd-oai
    closed this as completedin #9134on Jan 13, 2026
  9. hdcodedev
    added a commit that references this issue on Jan 13, 2026

    fix(windows-sandbox-rs) bump SETUP_VERSION (openai#9134)

    ebacd28
  10. dylan-hurd-oai
    reopened this on Jan 14, 2026

  11. dylan-hurd-oai commented on Jan 14, 2026

    @dylan-hurd-oai
    dylan-hurd-oai
    on Jan 14, 2026
    Contributor

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

  12. Cooad commented on Jan 20, 2026

    @Cooad
    Cooad
    on Jan 20, 2026

    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

  13. tagorr commented on Jan 20, 2026

    @tagorr
    tagorr
    on Jan 20, 2026
    Author

    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.

  14. 12 remaining items

  15. TenofHearts commented on Apr 20, 2026

    @TenofHearts
    TenofHearts
    on Apr 20, 2026

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

  16. nicolasdemol commented on Apr 23, 2026

    @nicolasdemol
    nicolasdemol
    on Apr 23, 2026

    Quick fix : Reinstall Codex App

  17. TenofHearts commented on Apr 23, 2026

    @TenofHearts
    TenofHearts
    on Apr 23, 2026

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

  18. ruiheng commented on Apr 24, 2026

    @ruiheng
    ruiheng
    on Apr 24, 2026

    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.

  19. YdayangY commented on Apr 24, 2026

    @YdayangY
    YdayangY
    on Apr 24, 2026

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

  20. hudrazine commented on Apr 24, 2026

    @hudrazine
    hudrazine
    on Apr 24, 2026

    @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!

  21. yongzheJIN commented on May 13, 2026

    @yongzheJIN
    yongzheJIN
    on May 13, 2026

    @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?

  22. HYP3R00T commented on Jul 15, 2026

    @HYP3R00T
    HYP3R00T
    on Jul 15, 2026

    Any progress?

  23. tagorr commented on Jul 15, 2026

    @tagorr
    tagorr
    on Jul 15, 2026
    Author

    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?

  24. HOS459 commented on Jul 16, 2026

    @HOS459
    HOS459
    on Jul 16, 2026

    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

  25. HOS459 commented on Jul 16, 2026

    @HOS459
    HOS459
    on Jul 16, 2026

    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

  26. IDanielRosell commented on Jul 18, 2026

    @IDanielRosell
    IDanielRosell
    on Jul 18, 2026

    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

  27. LukasWillin commented on Jul 20, 2026

    @LukasWillin
    LukasWillin
    on Jul 20, 2026

    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?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions