Codex desktop on Windows cannot start PowerShell host in session (8009001d)

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

• #13340

Powered by Codex Action

Not a duplicate no

I can reproduce the same issue on Windows.

What I verified:

• powershell.exe -NoLogo -NoProfile starts normally outside Codex Desktop.
• PowerShell 7.5.4 (pwsh) also installs and starts normally.
• The bundled Codex CLI binary starts normally and codex.exe --help works.
• In Codex Desktop, any internal command execution fails before the command actually runs, with the same 8009001d PowerShell host error.
• Changing Integrated terminal shell from PowerShell to Command Prompt in Codex Desktop does not fix the issue.
• Restarting Windows does not fix it.
• Reinstalling Codex Desktop does not fix it.

Additional details:

• This does not look like a broken system PowerShell installation, because standalone powershell.exe works.
• It also does not look like a broken Codex backend binary, because codex.exe --help works.
• The failure appears to be specific to the Codex Desktop internal command/session host on Windows.

PowerShell checks:

• powershell.exe -NoLogo -NoProfile -> works
• pwsh -NoLogo -NoProfile -> works

Codex backend check:

• ...\\vendor\\x86_64-pc-windows-msvc\\codex\\codex.exe --help -> works

My current conclusion:

• The issue seems to be in Codex Desktop’s Windows session/PTY/process environment when starting the internal PowerShell host, not in Windows PowerShell itself.

If useful, I can also provide the exact Codex Desktop version from “About Codex”.

我在Windows系统上也遇到了同样的问题。 我核实的内容： powershell.exe -NoLogo -NoProfile正常情况下，在 Codex Desktop 之外即可启动。 PowerShell 7.5.4 ( pwsh) 也能正常安装和启动。 捆绑的 Codex CLI 二进制文件可以正常启动并codex.exe --help运行。 在 Codex Desktop 中，任何内部命令的执行都会在命令实际运行之前失败，并出现相同的8009001dPowerShell 主机错误。 Integrated terminal shell在 Codex Desktop 中将值从更改PowerShell为Command Prompt并不能解决问题。 重启Windows系统也无法解决问题。 重新安装 Codex Desktop 也无法解决问题。 更多详情： 这看起来不像是一个损坏的系统 PowerShell 安装，因为独立powershell.exe运行是正常的。 它看起来也不像是 Codex 后端二进制文件损坏了，因为codex.exe --help它可以正常工作。 该故障似乎是 Windows 系统上 Codex Desktop 内部命令/会话主机特有的。 PowerShell 检查： powershell.exe -NoLogo -NoProfile-> 有效 pwsh -NoLogo -NoProfile-> 有效 Codex 后端检查： ...\\vendor\\x86_64-pc-windows-msvc\\codex\\codex.exe --help-> 有效 我目前的结论是： 问题似乎出在 Codex Desktop 的 Windows 会话/PTY/进程环境中，启动内部 PowerShell 主机时，而不是 Windows PowerShell 本身。 如果需要，我还可以提供“关于 Codex”中的 Codex Desktop 确切版本。

same problem

I found a solution that worked for me:

1. Uninstall the Codex desktop app
2. 2. Uninstall Codex CLI
3. 3. Delete the following folders if they exist:
4. - C:\Users\<your_pc_username>\AppData\Local\Codex
5. - C:\Users\<your_pc_username>\AppData\Roaming\Codex
6. - C:\Users\<your_pc_username>\.codex
7. 4. Reinstall Codex

After doing this, the issue was resolved for me. Hope it helps!

I also found a solution (using codex):

The fix was to tell Codex to inject two missing Windows environment variables into every shell it starts.

Why this matters:

• COMSPEC tells Windows where cmd.exe lives
• PATHEXT tells PowerShell which file extensions count as executable commands, like .EXE, .CMD, .BAT

In your broken Codex shell environment:

• COMSPEC was empty
• PATHEXT had only .CPL

That made normal commands like rg, git, python, and cmd fail even though they were installed.

I fixed it by adding these lines to Codex’s config:

• COMSPEC = "C:\\Windows\\System32\\cmd.exe"
• PATHEXT = ".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW"

That is your per-user Codex config directory:

• folder: C:\Users\[UserName]\.codex
• file: C:\Users\[UserName]\.codex\config.toml

Not sure if this is a good permanent solution but it's working for me for the time being.

I found a solution that worked for me: 1. Uninstall the Codex desktop app 2. 2. Uninstall Codex CLI 3. 3. Delete the following folders if they exist: 4. C:\Users\<your_pc_username>\AppData\Local\Codex 5. C:\Users\<your_pc_username>\AppData\Roaming\Codex 6. * C:\Users\<your_pc_username>\.codex 7. 4. Reinstall Codex After doing this, the issue was resolved for me. Hope it helps!

I found this work，I deleted codex in windsurf ,and the windsurf ,and the codex app got worked.

I hit the same desktop-session failure on Windows Codex app 26.306.996.0 while working inside the app.

What I saw in this session

• Every shell command initially failed before execution with:

Internal Windows PowerShell error. Loading managed Windows PowerShell failed with error 8009001d.

• This happened even for trivial commands like Get-Location, gh auth status, and Get-ChildItem.
• PowerShell on the same machine works outside Codex.
• Later in the same general app session, the command path recovered and those commands started working again.

Why this may matter

• The transient recovery suggests this may not just be a permanently broken machine setup; there may be a session/host initialization or environment inheritance bug.
• The official node-pty troubleshooting docs mention this exact 8009001d startup failure in connection with missing SystemRoot when PowerShell is launched.
• That also seems consistent with earlier Windows env-inheritance reports such as #4180 and #3311.

If helpful, I can provide the exact failed command list and timestamps from this session.

I found a config-only workaround on Windows Codex Desktop 26.306.996.0 that stopped this from reproducing for me.

Working config:

[shell_environment_policy.set]
SystemRoot = C:\\Windows
windir = C:\\Windows

[windows]
sandbox = unelevated

Important caveat:

• My earlier failing state had [windows] sandbox = elevated.
• After switching that to unelevated, commands inside Codex Desktop started working again.
• However, the working config above also explicitly injects SystemRoot and windir, so I cannot cleanly isolate whether the decisive factor is:

1. unelevated alone
2. env injection alone
3. the combination

What this does seem to narrow down:

• This does not look like a broken PowerShell installation, because PowerShell works outside Codex.
• It also makes the bug look less like a generic shell failure and more like either:
• a problem specific to the elevated Windows sandbox path, and/or
• missing critical inherited Windows environment variables in the Codex-hosted shell/session path

Current result with the working config:

• Get-Location works
• gh auth status works
• Get-ChildItem works

So at minimum, this seems to be a useful narrowing signal: elevated vs unelevated matters here, and SystemRoot / windir also appear relevant.

I found a config-only workaround on Windows Codex Desktop 26.306.996.0 that stopped this from reproducing for me. Working config: [shell_environment_policy.set] SystemRoot = C:\\Windows windir = C:\\Windows [windows] sandbox = unelevated Important caveat: My earlier failing state had [windows] sandbox = elevated. After switching that to unelevated, commands inside Codex Desktop started working again. However, the working config above also explicitly injects SystemRoot and windir, so I cannot cleanly isolate whether the decisive factor is: 1. unelevated alone 2. env injection alone 3. the combination What this does seem to narrow down: This does not look like a broken PowerShell installation, because PowerShell works outside Codex. It also makes the bug look less like a generic shell failure and more like either: a problem specific to the elevated Windows sandbox path, and/or missing critical inherited Windows environment variables in the Codex-hosted shell/session path Current result with the working config: Get-Location works gh auth status works Get-ChildItem works So at minimum, this seems to be a useful narrowing signal: elevated vs unelevated matters here, and SystemRoot / windir also appear relevant.

thanks, it works for me

我也遇到了这个问题，试了上面的解决方法也没行，有没有大佬能提供下其他方法

I found a config-only workaround on Windows Codex Desktop that stopped this from reproducing for me.26.306.996.0 Working config: [shell_environment_policy.set] SystemRoot = C:\\Windows windir = C:\\Windows [windows] sandbox = unelevated Important caveat: My earlier failing state had .[windows] sandbox = elevated After switching that to , commands inside Codex Desktop started working again.unelevated However, the working config above also explicitly injects and , so I cannot cleanly isolate whether the decisive factor is: SystemRootwindir 1. unelevated alone 2. env injection alone 3. the combination What this does seem to narrow down: This does not look like a broken PowerShell installation, because PowerShell works outside Codex. It also makes the bug look less like a generic shell failure and more like either: a problem specific to the elevated Windows sandbox path, and/or missing critical inherited Windows environment variables in the Codex-hosted shell/session path Current result with the working config: Get-Location works gh auth status works Get-ChildItem works So at minimum, this seems to be a useful narrowing signal: vs matters here, and / also appear relevant.elevatedunelevatedSystemRootwindir

thanks, it works for me.

Working config:  工作配置： [shell_environment_policy.set] SystemRoot = C:\\Windows windir = C:\\Windows [windows] sandbox = unelevated

I edited it the way you said, and now it works. Thanks

Working config: [shell_environment_policy.set] SystemRoot = C:\\Windows windir = C:\\Windows [windows] sandbox = unelevated

This also fixed it for me, except I needed 'C:\\Windows' as a literal string. I did not need to change the sandbox to unelevated, it's still elevated in my config.

[shell_environment_policy]
inherit = "core"
exclude = ["_TOKEN", "_KEY", "*_SECRET"]
set = { SystemRoot = "C:\\Windows", windir = "C:\\Windows" }

I found a config-only workaround on Windows Codex Desktop 26.306.996.0 that stopped this from reproducing for me. Working config: [shell_environment_policy.set] SystemRoot = C:\\Windows windir = C:\\Windows [windows] sandbox = unelevated Important caveat: My earlier failing state had [windows] sandbox = elevated. After switching that to unelevated, commands inside Codex Desktop started working again. However, the working config above also explicitly injects SystemRoot and windir, so I cannot cleanly isolate whether the decisive factor is: 1. unelevated alone 2. env injection alone 3. the combination What this does seem to narrow down: This does not look like a broken PowerShell installation, because PowerShell works outside Codex. It also makes the bug look less like a generic shell failure and more like either: a problem specific to the elevated Windows sandbox path, and/or missing critical inherited Windows environment variables in the Codex-hosted shell/session path Current result with the working config: Get-Location works gh auth status works Get-ChildItem works So at minimum, this seems to be a useful narrowing signal: elevated vs unelevated matters here, and SystemRoot / windir also appear relevant.

对我来说看起来有效，不过工具提示需要增加引号

[shell_environment_policy.set]
SystemRoot = "C:\\Windows"
windir = "C:\\Windows"

[windows]
sandbox = "unelevated"

Don‘t use sandbox!!!

1. uninstall codex
2. rm .codex
3. install codex
4. init without sandbox

Don‘t use sandbox!!! 1. uninstall codex 2. rm .codex 3. install codex 4. init without sandbox

it is not safe bro

I can confirm this on Windows too.

I tested both:

• VS Code ChatGPT/Codex extension
• Codex App for Windows

Same result in both: PowerShell/session host fails before command execution with error 8009001d.

What I verified:

• PowerShell works normally outside Codex
• SystemRoot is set correctly
• Full access does not help
• Reinstall/restart did not help

This seems broader than just the desktop app issue and may affect the VS Code integration on Windows as well.

I found a helpful methods：

Uninstall the Codex desktop app
Uninstall Codex CLI
Delete the following folders if they exist:
C:\Users\<your_pc_username>\AppData\Local\Codex
C:\Users\<your_pc_username>\AppData\Roaming\Codex
C:\Users\<your_pc_username>\.codex
Reinstall Codex , important! Reinstall Codex for windows app ,not Codex Cli, Now you can use Codex app to read your local doc!!
After doing this, the issue was resolved for me. Hope it helps!

I feel bad I still can't figure it out.

I hit the same 8009001d PowerShell startup failure on Windows.
In my case, PowerShell itself was fine outside Codex, but any shell command inside Codex failed before execution, even simple ones like:

Get-Location
Get-ChildItem -Force

The error was:

Internal Windows PowerShell error.
Loading managed Windows PowerShell failed with error 8009001d.

What fixed it for me was updating:

C:\Users\<YourUser>\.codex\config.toml

and explicitly setting these Windows environment variables:

[env]
COMSPEC = "C:\\Windows\\System32\\cmd.exe"
PATHEXT = ".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW"
SystemRoot = "C:\\Windows"
windir = "C:\\Windows"

[shell_environment_policy]
inherit = "core"

[shell_environment_policy.set]
COMSPEC = "C:\\Windows\\System32\\cmd.exe"
PATHEXT = ".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW"
SystemRoot = "C:\\Windows"
windir = "C:\\Windows"

[windows]
sandbox = "unelevated"

After that, I fully restarted Codex and PowerShell commands started working again.

> 我在Windows系统上也遇到了同样的问题。 > 我核实的内容： > > powershell.exe -NoLogo -NoProfile正常情况下，在 Codex Desktop 之外即可启动。 > PowerShell 7.5.4 ( pwsh) 也能正常安装和启动。 > 捆绑的 Codex CLI 二进制文件可以正常启动并codex.exe --help运行。 > 在 Codex Desktop 中，任何内部命令的执行都会在命令实际运行之前失败，并出现相同的8009001dPowerShell 主机错误。 > Integrated terminal shell在 Codex Desktop 中将值从更改PowerShell为Command Prompt并不能解决问题。 > 重启Windows系统也无法解决问题。 > 重新安装 Codex Desktop 也无法解决问题。 > > 更多详情： > > 这看起来不像是一个损坏的系统 PowerShell 安装，因为独立powershell.exe运行是正常的。 > 它看起来也不像是 Codex 后端二进制文件损坏了，因为codex.exe --help它可以正常工作。 > 该故障似乎是 Windows 系统上 Codex Desktop 内部命令/会话主机特有的。 > > PowerShell 检查： > > powershell.exe -NoLogo -NoProfile-> 有效 > pwsh -NoLogo -NoProfile-> 有效 > > Codex 后端检查： > > ...\\vendor\\x86_64-pc-windows-msvc\\codex\\codex.exe --help-> 有效 > > 我目前的结论是： > > 问题似乎出在 Codex Desktop 的 Windows 会话/PTY/进程环境中，启动内部 PowerShell 主机时，而不是 Windows PowerShell 本身。 > > 如果需要，我还可以提供“关于 Codex”中的 Codex Desktop 确切版本。 same problem

I also encountered the same problem （windows11 ARM）

I found a config-only workaround on Windows Codex Desktop 26.306.996.0 that stopped this from reproducing for me. Working config: [shell_environment_policy.set] SystemRoot = C:\\Windows windir = C:\\Windows [windows] sandbox = unelevated Important caveat: My earlier failing state had [windows] sandbox = elevated. After switching that to unelevated, commands inside Codex Desktop started working again. However, the working config above also explicitly injects SystemRoot and windir, so I cannot cleanly isolate whether the decisive factor is: 1. unelevated alone 2. env injection alone 3. the combination What this does seem to narrow down: This does not look like a broken PowerShell installation, because PowerShell works outside Codex. It also makes the bug look less like a generic shell failure and more like either: a problem specific to the elevated Windows sandbox path, and/or missing critical inherited Windows environment variables in the Codex-hosted shell/session path Current result with the working config: Get-Location works gh auth status works Get-ChildItem works So at minimum, this seems to be a useful narrowing signal: elevated vs unelevated matters here, and SystemRoot / windir also appear rele

I found a config-only workaround on Windows Codex Desktop 26.306.996.0 that stopped this from reproducing for me. Working config: [shell_environment_policy.set] SystemRoot = C:\\Windows windir = C:\\Windows [windows] sandbox = unelevated Important caveat: My earlier failing state had [windows] sandbox = elevated. After switching that to unelevated, commands inside Codex Desktop started working again. However, the working config above also explicitly injects SystemRoot and windir, so I cannot cleanly isolate whether the decisive factor is: 1. unelevated alone 2. env injection alone 3. the combination What this does seem to narrow down: This does not look like a broken PowerShell installation, because PowerShell works outside Codex. It also makes the bug look less like a generic shell failure and more like either: a problem specific to the elevated Windows sandbox path, and/or missing critical inherited Windows environment variables in the Codex-hosted shell/session path Current result with the working config: Get-Location works gh auth status works Get-ChildItem works So at minimum, this seems to be a useful narrowing signal: elevated vs unelevated matters here, and SystemRoot / windir also appear relevant.

I love you bro.

I hit the same issue on Windows. What fixed it for me was changing my Codex config from:
[shell_environment_policy]
inherit = "core"

to
[shell_environment_policy]
inherit = "all"


> I found a solution that worked for me: > > 1. Uninstall the Codex desktop app > 2. 2. Uninstall Codex CLI > 3. 3. Delete the following folders if they exist: > 4. C:\Users\<your_pc_username>\AppData\Local\Codex > 5. C:\Users\<your_pc_username>\AppData\Roaming\Codex > 6. * C:\Users\<your_pc_username>\.codex > 7. 4. Reinstall Codex > After doing this, the issue was resolved for me. Hope it helps! I found this work，I deleted codex in windsurf ,and the windsurf ,and the codex app got worked.

only delete C:\Users\<your_pc_username>\.codex ，codex can work

I was able to fix this issue on my machine (Windows) after several attempts. Sharing what worked for me:

Problem

Codex desktop could not start PowerShell host:

• Error 8009001d
• Sandbox could not start
• Commands failed to execute

Solution

1. Completely uninstall Codex (desktop app)

1. Delete ALL Codex-related local folders manually:

C:\Users\<your_username>\.codex
C:\Users\<your_username>\AppData\Local\Codex
C:\Users\<your_username>\AppData\Roaming\Codex
C:\Users\CodexSandboxOffline (if exists)

1. If any folder cannot be deleted (permission denied), run Command Prompt as Administrator:

rd /s /q C:\Users\CodexSandboxOffline

1. Reinstall Codex

1. Enable Agent Sandbox inside the app

1. If you see:

"Couldn't set up admin sandbox"

Click:
➡️ Use backup sandbox

Result

After this:

• Sandbox started successfully
• Terminal commands worked again (e.g. echo hello)
• No more PowerShell errors

---

Notes

• Changing shell (PowerShell / Git Bash / CMD) did NOT fix the issue
• The root cause seems to be corrupted local Codex cache / sandbox state

Hope this helps someone 👍
Environment:

• Windows 10/11
• Codex Desktop (latest version at time of writing)

This might be related to Windows cryptographic or user profile issues causing PowerShell startup failure.

Check if you have imported the configuration of an external Agent, such as Claude Code? If so, delete your config.toml and reopen codex.

我在 Windows 系统上也遇到了同样的问题。我的解决方法是将 Codex 配置从：更改 [shell_environment_policy] inherit = "core" 为： [shell_environment_policy] inherit = "all"

amazing！it work to me!!

I hit what appears to be the same root issue on Windows Codex Desktop, and I was able to narrow it down further.

Environment

• Codex Desktop: 26.409.1734.0
• Windows app config already had [windows] sandbox = "unelevated"
• Built-in PowerShell pane worked normally
• Agent shell_command calls failed before executing even trivial commands such as Get-Location

Observed failure

• Every agent shell call failed with:

Internal Windows PowerShell error. Loading managed Windows PowerShell failed with error 8009001d.

Important narrowing signal

• I could manually reproduce the same failure from the working built-in PowerShell pane with:

Start-Process powershell -NoNewWindow -UseNewEnvironment

• The same launch without -UseNewEnvironment worked.
• Manual direct PowerShell also worked:

powershell -NoProfile -Command "Write-Output ok"

That made this look less like a broken PowerShell install and more like Codex launching PowerShell with an overly reduced environment.

My Codex config before the fix was:

[shell_environment_policy]
inherit = "core"

[shell_environment_policy.set]
CLAUDE_CODE_GIT_BASH_PATH = 'C:\\Program Files\\Git\\bin\\bash.exe'

[windows]
sandbox = "unelevated"

What fixed it for me

• Change:

inherit = "core"

• To:

inherit = "all"

• Fully restart Codex Desktop

After that, agent shell commands started working immediately again. I verified both:

• powershell -NoProfile -Command ...
• Get-Location

Why this may matter

• In my case this was fixed without reinstalling Codex, deleting .codex, or injecting SystemRoot / windir / COMSPEC.
• So there seems to be a distinct failure mode where shell_environment_policy.inherit = "core" on Windows causes a PowerShell startup environment that is too stripped down, and changing it to inherit = "all" avoids the 8009001d failure.

This might help narrow the bug to the Windows environment inheritance policy used by the desktop shell bridge.

我还找到了一个解决方案（使用了 Codex）： 解决办法是让 Codex 在启动的每个 shell 中注入两个缺失的 Windows 环境变量。 为什么这很重要： COMSPEC 告诉 Windows cmd.exe 的位置 PATHEXT 告诉 PowerShell 哪些文件扩展名被视为可执行命令，例如 .EXE、.CMD、.BAT 。 在您损坏的 Codex 壳环境中： COMSPEC是空的 PATHEXT 中只有 .CPL 这一种扩展名。 这导致像 rg、git、python 和 cmd 这样的常规命令即使已安装也无法正常运行。 我通过在 Codex 的配置中添加这些行解决了这个问题： COMSPEC = "C:\Windows\System32\cmd.exe" PATHEXT = ".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW" 这是您每个用户的 Codex 配置目录： 文件夹：C:\Users[用户名].codex 文件：C:\Users[用户名].codex\config.toml 不确定这是否是一个好的长久之计，但目前对我而言是管用的。

Useful

I can reproduce this in Codex Desktop on Windows. I tested this again in a fresh Codex Desktop thread. PowerShell works normally outside Codex, and cmd.exe also works normally outside Codex. Inside Codex, every shell execution fails before the actual command runs.

Observed error:

Internal Windows PowerShell error. Loading managed Windows PowerShell failed with error 8009001d.

Important detail: this does not appear to be only a PowerShell problem in my local environment. Even when the assistant tries to run cmd.exe /c echo CMD OK, the execution still fails with the same PowerShell host startup error before cmd.exe actually runs.

What I verified:

• PowerShell works fine outside Codex Desktop
• cmd.exe works fine outside Codex Desktop
• Restarting Codex Desktop did not fix it
• Reopening a fresh thread did not fix it
• The issue persists in the current Codex Desktop session

From my side this looks like a Codex Desktop Windows shell-host / process-launch bug, not a broken local PowerShell installation.

Windows Codex Desktop에서도 비슷한 근본적인 문제를 발견했는데, 원인을 좀 더 좁힐 수 있었습니다. 환경 Codex Desktop: 26.409.1734.0 Windows 앱 구성은 이미 있었습니다.[windows] sandbox = "unelevated" 내장 PowerShell 창이 정상적으로 작동했습니다. 에이전트 shell_command호출이 사소한 명령조차 실행하기 전에 실패했습니다.Get-Location 관찰된 실패 모든 에이전트 셸 호출이 다음 오류와 함께 실패했습니다. Internal Windows PowerShell error. Loading managed Windows PowerShell failed with error 8009001d. 중요한 협착 신호 정상적으로 작동하는 내장 PowerShell 창에서 다음과 같은 명령어를 사용하여 동일한 오류를 수동으로 재현할 수 있었습니다. Start-Process powershell -NoNewWindow -UseNewEnvironment 동일한 실행 방식이 -UseNewEnvironment작동하지 않았습니다. 수동으로 PowerShell에 직접 연결하는 방법도 작동했습니다. powershell -NoProfile -Command "Write-Output ok" 그 때문에 이는 PowerShell 설치 오류라기보다는 Codex가 지나치게 축소된 환경으로 PowerShell을 실행하는 것처럼 보였습니다. 수정 전 제 Codex 설정은 다음과 같았습니다. [shell_environment_policy] inherit = "core" [shell_environment_policy.set] CLAUDE_CODE_GIT_BASH_PATH = 'C:\\Program Files\\Git\\bin\\bash.exe' [windows] sandbox = "unelevated" 제 경우에는 이렇게 하니 해결됐습니다. 변화: inherit = "core" 에게: inherit = "all" Codex Desktop을 완전히 다시 시작하십시오. 그 후 에이전트 셸 명령이 즉시 다시 작동하기 시작했습니다. 두 가지 모두 확인했습니다. powershell -NoProfile -Command ... Get-Location 이것이 중요한 이유 제 경우에는 Codex를 재설치하거나, ​​삭제 .codex하거나, SystemRoot/ windir/ ​​를 삽입하지 않고도 이 문제가 해결되었습니다 COMSPEC. * shell_environment_policy.inherit = "core"따라서 Windows에서 PowerShell 시작 환경이 너무 단순화되어 발생하는 명확한 오류 모드가 있는 것으로 보이며 , 이를 수정하면 오류가 발생 inherit = "all"하지 않습니다 8009001d. 이렇게 하면 데스크톱 셸 브리지에서 사용하는 Windows 환경 상속 정책과 관련된 버그인지 범위를 좁히는 데 도움이 될 수 있습니다.

Environment:

• Codex Desktop: 26.415.4716.0
• Windows 11 25H2

Issue:

• When launching PowerShell from the Codex app, I got this error:

error: "windows sandbox: runner error: CreateProcessAsUserW failed: 1920" }

Fix:

• I applied the following two settings in config.toml:
• [windows] sandbox = "unelevated"
• [shell_environment_policy] inherit = "all"

Thanks to your comment, I was able to fix it without uninstalling and reinstalling the app. Thank you. The key point in my case was updating the sandbox and inherit settings.

I encountered a similar problem. The Codex app had an issue running PowerShell and couldn't use any commands.

codex execution error: Io(Custom { kind: Other, error: "windows sandbox: runner error: CreateProcessAsUserW failed: 1920" })

I suspect this is related to the default installation method for PowerShell 7 via MSIX. When using the default installation method with winget, it installs via MSIX by default:

winget install --id Microsoft.PowerShell --source winget

If installed via the MSI method, the location is $Env:ProgramFiles\PowerShell\7.

~ > $PSHOME
C:\Program Files\PowerShell\7

If installed via the MSIX method, the location is $Env:ProgramFiles\WindowsApps.

~ > $PSHOME
C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.1.0_x64__8wekyb3d8bbwe

However, ProgramFiles\WindowsApps is a highly protected directory.
MSIX applications are sandboxed, limiting their access to other parts of the system.

After uninstalling the previously MSIX-installed PowerShell 7 and then reinstalling it via MSI, Codex was able to launch PowerShell 7 normally.

References:

• https://learn.microsoft.com/powershell/scripting/install/installing-powershell
• https://github.com/PowerShell/PowerShell/discussions/27292
• https://devblogs.microsoft.com/powershell/powershell-msi-deprecation/
• https://learn.microsoft.com/en-us/windows/msix/overview

Are you on Windows Home? Since Home doesn't support Sandbox, try switching Codex sandbox to unelevated mode, it should work.
[windows]
sandbox = "unelevated"

I hit the same issue on Windows. What fixed it for me was changing my Codex config from:我在 Windows 上遇到了同样的问题。对我有效的解决方案是将我的 Codex 配置从以下内容更改： [shell_environment_policy] inherit = "core" to  到 [shell_environment_policy] inherit = "all"

Useful!!!

> Windows Codex Desktop에서도 비슷한 근본적인 문제를 발견했는데, 원인을 좀 더 좁힐 수 있었습니다. > 환경 > > Codex Desktop: 26.409.1734.0 > Windows 앱 구성은 이미 있었습니다.[windows] sandbox = "unelevated" > 내장 PowerShell 창이 정상적으로 작동했습니다. > 에이전트 shell_command호출이 사소한 명령조차 실행하기 전에 실패했습니다.Get-Location > > 관찰된 실패 > > 모든 에이전트 셸 호출이 다음 오류와 함께 실패했습니다. > Internal Windows PowerShell error. Loading managed Windows PowerShell failed with error 8009001d. > > 중요한 협착 신호 > > 정상적으로 작동하는 내장 PowerShell 창에서 다음과 같은 명령어를 사용하여 동일한 오류를 수동으로 재현할 수 있었습니다. > Start-Process powershell -NoNewWindow -UseNewEnvironment > 동일한 실행 방식이 -UseNewEnvironment작동하지 않았습니다. > 수동으로 PowerShell에 직접 연결하는 방법도 작동했습니다. > powershell -NoProfile -Command "Write-Output ok" > > 그 때문에 이는 PowerShell 설치 오류라기보다는 Codex가 지나치게 축소된 환경으로 PowerShell을 실행하는 것처럼 보였습니다. > 수정 전 제 Codex 설정은 다음과 같았습니다. > [shell_environment_policy] > inherit = "core" > [shell_environment_policy.set] > CLAUDE_CODE_GIT_BASH_PATH = 'C:\Program Files\Git\bin\bash.exe' > [windows] > sandbox = "unelevated" > 제 경우에는 이렇게 하니 해결됐습니다. > > 변화: > inherit = "core" > 에게: > inherit = "all" > Codex Desktop을 완전히 다시 시작하십시오. > > 그 후 에이전트 셸 명령이 즉시 다시 작동하기 시작했습니다. 두 가지 모두 확인했습니다. > > powershell -NoProfile -Command ... > Get-Location > > 이것이 중요한 이유 > > 제 경우에는 Codex를 재설치하거나, ​​삭제 .codex하거나, SystemRoot/ windir/ ​​를 삽입하지 않고도 이 문제가 해결되었습니다 COMSPEC. > shell_environment_policy.inherit = "core"따라서 Windows에서 PowerShell 시작 환경이 너무 단순화되어 발생하는 명확한 오류 모드가 있는 것으로 보이며 , 이를 수정하면 오류가 발생 inherit = "all"하지 않습니다 8009001d. > > 이렇게 하면 데스크톱 셸 브리지에서 사용하는 Windows 환경 상속 정책과 관련된 버그인지 범위를 좁히는 데 도움이 될 수 있습니다. Environment: Codex Desktop: 26.415.4716.0 Windows 11 25H2 Issue: When launching PowerShell from the Codex app, I got this error: error: "windows sandbox: runner error: CreateProcessAsUserW failed: 1920" } Fix: I applied the following two settings in config.toml: [windows] sandbox = "unelevated" * [shell_environment_policy] inherit = "all" Thanks to your comment, I was able to fix it without uninstalling and reinstalling the app. Thank you. The key point in my case was updating the sandbox and inherit settings.

This appears to have worked for me.

https://github.com/openai/codex/pull/20089 should address the problem where inherit = "core" doesn't work on Windows.