Windows desktop shell resolves user PATH rg.exe before Codex-bundled rg.exe
What version of the Codex App are you using
Codex desktop app on Windows. Version: 26.506.31421
What subscription do you have?
- Plus
What platform is your computer?
Windows 11 / Windows 10.0.26100 x64 / PowerShell 7.6.1
What issue are you seeing?
Codex shell commands resolve rg from the user PATH before using the Codex-bundled ripgrep binary. This is both an annoyance in that ripgrep fails, but if rg.exe had resolved to an unexpected program then it could be a potential destructive or security issue.
In my Codex session, Get-Command rg resolved to:
C:\Users\jim\AppData\Local\Microsoft\WinGet\Links\rg.exe
A command using rg --files failed in the Codex shell with:
No application is associated with the specified file for this operation
However, the Codex-bundled ripgrep binary works:
C:\Users\jim\AppData\Local\OpenAI\Codex\bin\rg.exe --version
returns:
ripgrep 15.1.0
Why this matters
Codex should prefer its own bundled tool binaries for tools it relies on, especially short names like rg, rather than resolving arbitrary executables from the user's PATH first.
This is both a reliability issue and a security hardening issue. If a user has another rg.exe earlier on PATH, intentionally or accidentally, Codex may execute that instead of the expected bundled ripgrep. A malicious or broken executable named rg.exe could cause unexpected side effects.
The user should be able to install ripgrep, or any other program named rg.exe on their computer without worrying about it breaking Codex or producing undesired side effects.
What steps can reproduce the bug?
- On Windows, install Codex desktop.
- Ensure another
rg.exeis available earlier on PATH, such as the WinGet Links shim:
- install with
winget install -e --id BurntSushi.ripgrep.MSVC - places the following on the path
C:\Users\<user>\AppData\Local\Microsoft\WinGet\Links\rg.exe- Better yet, add another program called
rg.exeto your path.
- Start a Codex desktop session.
- Run:
Get-Command rg
- Run:
rg --files
- Or anything that triggers a call to
rg.exe
Workaround
Using the bundled binary directly works:
C:\Users\jim\AppData\Local\OpenAI\Codex\bin\rg.exe --files
What is the expected behavior?
For bundled operational dependencies, Codex should either invoke absolute paths or prepend its managed tool directory ahead of user-controlled PATH entries in agent shell sessions.
Additional information
Realistically it should never assume a program is trustable just based on the name. Obviously there are some valid dependencies, but adopting a external dependency requires consideration.
2 Comments
I can independently reproduce this issue in a newer Codex Desktop build, tested on 2026-07-15.
Environment:
Inside the Codex tool shell:
The WinGet symlink is resolved before the Codex-managed copy:
A bare invocation still fails:
The WinGet symlink target exists, but invoking the real target directly from the Codex sandbox returns
Access denied.The Codex-bundled binary works correctly when discovered and invoked directly:
This confirms that the PATH shadowing / Windows sandbox compatibility issue remains reproducible in a newer Desktop build. Calling the bundled binary directly remains a working workaround.
I can reproduce this on Windows as well.
In the Codex shell,
Get-Command rgresolves to:``
text
``C:\Users\<user>\AppData\Local\Microsoft\WinGet\Links\rg.exe
Running
rg --versionwithout elevation fails with:``
text
``No application is associated with the specified file for this operation
However, running the same command with elevated privileges succeeds:
``
text
``ripgrep 15.2.0
The bundled binary also works without elevation:
``
text
``C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\ada252862d154cdd\rg.exe --version
This suggests the WinGet path itself is not necessarily broken; the failure may be related to the Codex shell sandbox or its ability to execute the WinGet shim/link. The user’s normal terminal can execute the same
rg.exesuccessfully.This further supports resolving Codex-managed dependencies using absolute paths, or ensuring the bundled tool directory takes precedence over user-controlled PATH entries.