windows codex app lost php.exe

Open 💬 2 comments Opened Mar 28, 2026 by Nana-Kusa
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.
I observed a case on Windows 11 Home where an executable that is available on PATH in a normal terminal is not recognized by Codex's command execution environment.

In this case, the executable was PHP.

Observed behavior
- In a normal PowerShell session, both `where.exe php` and `php -v` run successfully
- However, when running `php -v` from Codex, it fails with an error indicating that the `php` command cannot be found
- The behavior changed depending on where `php.exe` was located

Environment
- OS: Windows 10 home 
- Target command: `php` installed winget

What I confirmed
1.
When `php.exe` was located at the following path and that location was added to PATH, `php -v` worked in normal PowerShell, but Codex could not recognize `php`.

`C:\Users\mail_\AppData\Local\Microsoft\WinGet\Packages\PHP.PHP.8.5_Microsoft.Winget.Source_xxxxxxxx\php.exe`

2.
When `php.exe` was moved to the following location and that location was added to PATH, Codex was also able to run `php -v` successfully.

`C:\Program Files\php\php.exe`

Expected behavior
- On Windows, if an executable is available on PATH, Codex should recognize it in the same way as a normal terminal
- If there are restrictions on which PATH entries or executable directories Codex can use, that should be clearly documented or surfaced in the UI

Additional notes
- I understand that Codex may need to be restarted after PATH changes
- However, even after restarting Codex, `php.exe` under `AppData\Local\Microsoft\WinGet\Packages\...` was still not recognized
- In contrast, placing it at `C:\Program Files\php\php.exe` worked correctly

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 5 months ago

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

  • #15586
  • #15174
  • #15389

Powered by Codex Action

Nana-Kusa · 5 months ago

Thanks — after reviewing the linked issue more closely, I think mine may be related but not identical.

In #15174, the reported failure is specifically explained by a corrupted PATHEXT in the spawned shell, where bare command names fail to resolve but full-path .exe invocation still works, and restoring PATHEXT fixes the problem immediately.

My case appears different: normal PowerShell invocation failed even for some absolute-path executables, while the same binaries still launched successfully via .NET System.Diagnostics.ProcessStartInfo in the same session.

So both issues may belong to the broader category of Windows child-process environment / process-launch bugs in Codex Desktop, but I do not think #15586 is a pure duplicate of #15174.