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

[tagorr]

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)

sandbox.log

[openresearchtools]

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

[openresearchtools]

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)

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.

[tagorr]

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.

[dylan-hurd-oai]

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

[tagorr]

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.

[dylan-hurd-oai]

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

[Cooad]

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