Codex can't run echo $env:PATH

[davidgilbertson]

What version of Codex CLI is running?

codex-cli 0.111.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.4

What platform is your computer?

No response

What terminal emulator and version are you using (if applicable)?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

I just asked a basic question about my environment and all commands it tried seemed to fail, even down to the simplest echo $env:PATH.

What steps can reproduce the bug?

Uploaded thread: 019ccff6-be83-7ab1-a4a2-226f010ae5bb

What is the expected behavior?

Not only should these not fail, but they shouldn't hang if they don't work.

A human knows that if they run echo $env:PATH it will almost certainly be done in a second, and if it isn't, a human is smart enough to know that something fishy is going on and thus abort the attempt. AI should be able to as well. If the harness said to the LLM "hey you ran echo $env:PATH 10 seconds ago and it hasn't returned yet, you wanna wait or kill it?" I'm pretty sure you'd get a smart answer out of the LLM.
With any attempt at running a command, the LLM could provide a 'check-in' time. Not quite a timeout, but an opportunity to decide whether to wait another n seconds or kill it and try something else (perhaps with partial results if the command results in some stream of output).

Additional information

No response

[github-actions]

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

• windows: All shell commands crash with "Could not load netstandard 2.0.0.0" at PowerShell startup stage #13340
• Codex desktop on Windows cannot start PowerShell host in session (8009001d) #13917
• When reading files using the CodeX CLI on Windows, the error "no output" occurs. #13234
• [Windows] read-only sandbox mode causes MCP shell_command to stall indefinitely — no function_call_output returned #13987

Powered by Codex Action

[davidgilbertson]

Those related issues look vaguely similar but different to this. I don't see any errors, the commands just hang.

Although I just tried with v0.112 and fails for all sorts of things but doesn't actually hang. I asked "Can you run the simplest command you can to output my path env var?"

And got:

• You want the current PATH environment variable from this Windows shell. I’m running the smallest direct command for
  that now.

• Ran echo $env:PATH
  └ (no output)

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

• echo $env:PATH returned no output in this shell wrapper, so I’m retrying with Write-Output, which is the direct
  PowerShell form.

• Ran Write-Output $env:PATH
  └ (no output)

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

• The wrapper isn’t executing bare PowerShell expressions as expected, so I’m invoking PowerShell explicitly to read
  PATH.

• Ran C:\Program Files\PowerShell\7\pwsh.exe -Command "$env:PATH"
  └ (no output)

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

• PowerShell invocation is also being swallowed by the wrapper here. I’m falling back to cmd, which should print PATH
  reliably.

• Ran cmd /c echo %PATH%
  └ (no output)

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

• The shell tool is failing before command output reaches me, so I’m trying an explicit executable path to avoid the
  wrapper ambiguity.

• Ran C:\Windows\System32\cmd.exe /c echo %PATH%
  └ (no output)

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

• I wasn’t able to get the value because the shell runner is currently failing immediately with exit code 1 and no
  stdout, even for direct cmd.exe / pwsh.exe invocations.

  The commands I tried were:

  echo $env:PATH
  Write-Output $env:PATH
  C:\Program Files\PowerShell\7\pwsh.exe -Command "$env:PATH"
  C:\Windows\System32\cmd.exe /c echo %PATH%

  If you want, I can keep debugging the shell runner itself, but the simplest local command for you to run manually is:

  $env:PATH

  Or in cmd:

  echo %PATH%

Does it work when tested on Windows internally, is this just me?

[MoreiraTv]

I have the same problem.

[SproutSeeds]

I verified the patched behavior on native Windows from the same SSH / network-logon path that previously produced empty output and -1073741502.

• the host currently has no sandbox setup marker or sandbox users file under C:\Users\codyr\.codex
• with the patched build, every probe command in that SSH / session 0 path now returns the targeted Windows restricted-token sandbox cannot launch reliably from this non-interactive or network-logon session until elevated Windows sandbox setup has completed... error with EXIT=1
• that includes direct powershell.exe, direct dotnet.exe --info, direct cmd.exe /c echo ok, direct reg.exe query HKCU\Environment, and the child powershell.exe / dotnet.exe / whoami /groups commands through sandboxed cmd.exe
• the sandbox log shows legacy sandbox: session_id=0 interactive=false remote_interactive=false network=true -> elevated setup required

The old SSH / network-logon failure mode is no longer reproducing on this host.
The guard is firing on the intended legacy restricted-token path and surfacing the setup-missing state directly.
This verifies the non-interactive / network-logon fix path: use the elevated sandbox-user runner when setup exists, or return a targeted setup-required error instead of empty output and -1073741502.

Code patch I validated:
SproutSeeds@8a7b560

Full verification branch:
https://github.com/SproutSeeds/codex/tree/sprout/issue-14015-windows-handoff