›_ Codex Issues
Codex Issues / #17094

Codex VS Code extension cannot execute any local shell command on Windows (PowerShell 8009001d / CreateProcessWithLogonW 1056)

Open 💬 3 comments Opened Apr 8, 2026 by fengxiaozi-liu
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the IDE extension are you using?

openai.chatgpt-26.325.31654-win32-x64

What subscription do you have?

plus

Which IDE are you using?

vscode

What platform is your computer?

Windows_NT x64 10.0.26200

What issue are you seeing?

The Codex VS Code extension cannot execute any local shell command in my environment.

Symptoms:

  • Any command executed by Codex fails before the command actually runs
  • Even minimal commands such as Get-Location fail
  • Codex cannot read local files such as feature.md
  • Manual PowerShell works normally
  • VS Code integrated terminal works normally

Observed errors:

  • Internal Windows PowerShell error with code 8009001d
  • Sometimes CreateProcessWithLogonW failed: 1056

What I verified:

  • powershell -NoProfile works correctly when run manually
  • SystemRoot, WINDIR, and ComSpec are present in my PowerShell environment
  • VS Code terminal works
  • code --status shows pty-host, OpenConsole.exe, powershell.exe, and codex.exe app-server are running
  • Reinstalling VS Code did not fix it
  • Reinstalling the extension and deleting the extension directory did not fix it
  • The same problem happens in a new Codex conversation

Environment:

  • VS Code 1.114.0
  • Windows 10.0.26200 x64
  • Extension version: openai.chatgpt-26.325.31654-win32-x64

Minimal reproduction:

  1. Open VS Code
  2. Open a workspace
  3. Start a Codex chat
  4. Ask Codex to run a minimal local command such as Get-Location
  5. The command fails with the errors above

<img width="859" height="207" alt="Image" src="https://github.com/user-attachments/assets/8f2b82bc-b5de-4c59-ae35-dcab7b7664bf" />

What steps can reproduce the bug?

I can provide code --status output and extension logs if needed.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

  • #15809
  • #15850
  • #16780

Powered by Codex Action

Daniel-Spagiari · 4 months ago

+1 — same bug, same Windows build (10.0.26200.8246), Codex CLI 0.121.0.

Timeline:

  • Codex was working normally earlier today
  • Mid-session (around 13:26 local time on 2026-04-16), all shell commands started failing with Windows PowerShell managed load error 8009001d
  • Correlates with KB5082417 + KB5083769 installed at 00:00 on the same day
  • System Event Log shows 17× DCOM 10005 errors and TPM-WMI 1801 errors starting at 13:26:53

Fixes attempted (none worked):

  • sfc /scannow (fixed corrupted files but bug persisted)
  • DISM /RestoreHealth
  • Full uninstall + cache clean + reinstall via npm
  • Downgrade to 0.120.0
  • Deleted CodexSandboxOffline / CodexSandboxOnline users + group + reinstalled (Codex recreated them fresh)
  • Config windows.sandbox = "unelevated"
  • Flag --dangerously-bypass-approvals-and-sandbox
  • Uninstalled KB5082417 and rebooted

Verified working when invoked externally:

  • powershell.exe -NoProfile -Command "..." — OK
  • powershell.exe -NoProfile -EncodedCommand ... — OK (CLIXML output normal)
  • powershell.exe -NoProfile -File script.ps1 — OK

Verified broken in Codex:

  • Every shell_command regardless of target (dir, Get-ChildItem, rg, git, even cmd /c dir)
  • Same error on Codex Desktop app (not just CLI)

Root cause hypothesis:
NTE_PROVIDER_DLL_FAIL (0x8009001D) comes from CNG Provider signature validation during in-process CLR hosting of System.Management.Automation.dll. External powershell.exe invocations bypass this path and work fine. Build 26200 appears to have regressed CNG behavior for managed assembly strong-name verification via hostfxr-based hosting.

Current workaround:
Running Codex inside WSL2 (Ubuntu) — works perfectly, confirms issue is Windows-side only.

Please consider shipping a release that spawns powershell.exe as external process (via std::process::Command) instead of in-process CLR hosting, at least as a fallback on Windows 11 build 26200+.

SpeedyCraftah · 2 months ago

This sandbox has been a nightmare for me ever since I started using Codex, and there is no way to disable it fully as Codex will not allow you to prompt anything until you set it up again. Looks like running Codex under WSL is the solution (which is good as it fits my use case well), but it honestly just looks like the Codex team has shipped a poor attempt at a sandbox for Windows. This is probably partially an issue with Windows itself, but it still doesn't mean it should've been shipped for Codex.