Codex can't run echo $env:PATH

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

• #13340
• #13917
• #13234
• #13987

Powered by Codex Action

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?

I have the same problem.

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:
https://github.com/SproutSeeds/codex/commit/8a7b5609b37db1beecbb97a36aae055a832810d0

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