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
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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
PATHEXTin the spawned shell, where bare command names fail to resolve but full-path.exeinvocation still works, and restoringPATHEXTfixes 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.ProcessStartInfoin 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.