Windows: internal PowerShell tool fails with 8009001d while user PowerShell works

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

• #17325
• #18465

Powered by Codex Action

What's happening here? I see a lot of people over past 2 weeks with this... none of those seem to be resolved. I was working this morning. I had to restart and now "8009001d". Not a lot to go on to get "working" again

I literally am having to switching over to competitor product.. that in spite of everyone gushing over doesn't do as good of a job for what I have been working on. As such I end up spending twice as much time fixing its code than I do with GPT5.4...

I sincerely hope someone @ OpenAI with access to the codex source is actually looking the reports of the 8009001d issue.

I hit a very similar Windows failure pattern today. Sharing the triage path in case it helps separate the likely failure layers.

In my case, the important distinction was to test PowerShell startup itself before assuming Git, npm, gh, or project tooling was broken.

From a non-PowerShell shell such as cmd.exe, these were the most useful checks:

cmd /d /s /c ver
cmd /d /s /c pwsh -NoLogo -NoProfile -Command 1
cmd /d /s /c powershell -NoLogo -NoProfile -Command 1
cmd /d /s /c where pwsh
cmd /d /s /c where powershell
cmd /d /s /c git --version
cmd /d /s /c gh --version
cmd /d /s /c node --version
cmd /d /s /c codex --version

What I observed before reboot:

pwsh -NoLogo -NoProfile -Command 1
exit code: -2146232797
Process terminated.
The type initializer for 'System.Management.Automation.Runspaces.InitialSessionState' threw an exception.
System.ComponentModel.Win32Exception (126)
System.Management.Automation.Internal.SecuritySupport.GetSaferPolicy
System.Management.Automation.Security.SystemPolicy.GetAppLockerPolicy
System.Management.Automation.Security.SystemPolicy.GetSystemLockdownPolicy

Windows PowerShell also failed before command execution:

powershell -NoLogo -NoProfile -Command 1
exit code: -65536
output included Windows PowerShell startup failure text and 8009001d

At the same time, cmd.exe, git --version, gh --version, and node --version worked from cmd.exe. That suggests this class of failure should be treated as a shell/runtime launch failure first, not as a Git/GitHub/npm failure.

After a Windows reboot, the same checks recovered:

pwsh -NoLogo -NoProfile -Command 1        -> exit 0, output: 1
powershell -NoLogo -NoProfile -Command 1 -> exit 0, output: 1
git --version                            -> exit 0
gh --version                             -> exit 0
node --version                           -> exit 0
codex --version                          -> exit 0, codex-cli 0.125.0

So the root trigger is still unknown, but the most useful diagnostic split seems to be:

1. If pwsh -NoLogo -NoProfile -Command 1 fails, do not spend time on profile scripts or quoting yet. The failure is earlier than user command parsing.
2. If cmd.exe and the target CLIs work, do not classify this as a Git/GitHub/npm problem.
3. Preserve the exact pre-reboot shell output before restarting, because reboot may clear the bad state.
4. Also check the narrower environment-construction hypothesis from #19171:

``cmd
cmd /d /s /c "set PATH & set Path"
``

On Windows, duplicate PATH / Path entries in the spawned environment would be a strong signal that Codex is constructing a malformed process environment before PowerShell starts.

The InitialSessionState -> GetSaferPolicy -> GetAppLockerPolicy -> GetSystemLockdownPolicy stack also makes AppLocker / WDAC / SAFER policy lookup worth checking, especially when the failure happens before any actual command body runs.

I am seeing the same failure pattern on another Windows machine. Adding a compact repro/environment report.

Environment:

• Codex CLI: codex-cli 0.128.0
• npm package: @openai/codex@0.128.0
• npm latest: 0.128.0
• Codex Desktop / Microsoft Store app: 26.429.3425.0
• CLI path: C:\Users\gaola\AppData\Roaming\npm\codex
• winget upgrade --id 9PLM9XGG6VKS: no available upgrade
• pwsh: not installed

PowerShell works outside the Codex tool layer:

powershell.exe -NoProfile -Command '$PSVersionTable.PSVersion.ToString()'
# -> 5.1.26100.8115
# exit 0

Codex internal shell tool fails before command execution:

Exit code: -65536
Internal Windows PowerShell error. Loading managed Windows PowerShell failed with error 8009001d.

Observed impact:

• Any local shell work through the Codex app/tool layer is unusable.
• The same commands can be run through Git Bash / Claude Bash on the same machine.
• This appears to be in the Codex managed PowerShell host/tool invocation layer rather than Windows PowerShell itself.

Expected behavior:

• The tool should start PowerShell successfully, or fall back to another configured usable shell, or surface a clear remediation message when the managed PowerShell host cannot load.

Local downstream tracking issue for our environment: RT0305/AI_INFRASTRUCTURE#61.

Closing as a duplicate of #14057.