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

[aiajecom-cmd]

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

ChatGPT Pro

What platform is your computer?

"$([Environment]::OSVersion | ForEach-Object VersionString) $(if ([Environment]::Is64BitOperatingSystem) { "x64" } else { "x86" })"

What issue are you seeing?

Codex App on Windows cannot execute internal PowerShell commands via the Codex tool layer.

User PowerShell works normally in the same workspace, but Codex internal tool execution fails before even simple commands run.

Codex environment_context:

• cwd: D:\codex
• shell: powershell
• timezone: Asia/Seoul

User PowerShell works:

• Get-Date works
• Get-Location shows D:\codex.codex-tasks\design-md-analysis\packages\cli
• Test-Path D:\codex returns True

Codex internal tool fails:

• Get-Date
• Get-Location
• Test-Path D:\codex
• Test-Path D:\codex.codex-tasks\design-md-analysis
• bun --version
• node --version
• npm --version

All commands fail with:

• Exit code: -65536
• Output includes: 8009001d
• The output appears garbled/mojibake, but consistently contains Windows PowerShell and 8009001d.

This still happens after:

• restarting the Codex app
• running Codex as administrator
• updating/reinstalling the Codex app

Earlier there was also suspicion of a bad cwd mapping such as C:\mnt\d\codex, but in the current session environment_context reports D:\codex. However, Codex cannot confirm Get-Location because internal PowerShell execution fails first.

What steps can reproduce the bug?

Uploaded thread: 181a4917-b0ac-4581-8c77-5c51c136d27e

1. Open Codex App on Windows.
2. Open workspace D:\codex.
3. Confirm environment_context shows:
   • cwd: D:\codex
   • shell: powershell
4. Ask Codex to run any internal PowerShell command, for example:

   Get-Date

5. Observe that the command fails before execution with 8009001d.

Get-Location
Test-Path D:\codex
bun --version
node --version
npm --version

What is the expected behavior?

No response

Additional information

This does not appear to be a project/repository issue.

No package files were modified.
No install/build/test command was intentionally run.
The failure happens even with Get-Date, so it occurs before runtime PATH or project tooling becomes relevant.

[github-actions]

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

• Codex on VS Code(Windows) fails to start PowerShell for shell_command calls, causing all local shell operations to fail #17325
• Windows: tool-called PowerShell fails before command execution, even for trivial commands like 'exit 0' #18465

Powered by Codex Action

[Lithonite]

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.

[sean3808]

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 Windows: Codex 0.123.0 injects both PATH and Path into the shell environment, breaking PowerShell Env provider and causing intermittent shell startup failures #19171:

   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.

[RT0305]

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.