Windows desktop shell resolves user PATH rg.exe before Codex-bundled rg.exe

Open 💬 2 comments Opened May 12, 2026 by jimmckeeth

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?

  1. On Windows, install Codex desktop.
  2. Ensure another rg.exe is 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.exe to your path.
  1. Start a Codex desktop session.
  2. Run:

Get-Command rg

  1. Run:

rg --files

  1. 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.

View original on GitHub ↗

2 Comments

Ch1ldr3n · 1 month ago

I can independently reproduce this issue in a newer Codex Desktop build, tested on 2026-07-15.

Environment:

  • Codex Desktop: 26.707.9981.0
  • Windows 11 x64
  • PowerShell 7

Inside the Codex tool shell:

Get-Command rg -All | Select-Object CommandType, Source

The WinGet symlink is resolved before the Codex-managed copy:

C:\Users\<user>\AppData\Local\Microsoft\WinGet\Links\rg.exe
C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\<dynamic-version-dir>\rg.exe

A bare invocation still fails:

rg --version
Program 'rg.exe' failed to run:
No application is associated with the specified file for this operation.

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:

$codexRg = Get-ChildItem `
    "$env:LOCALAPPDATA\OpenAI\Codex\bin" `
    -Recurse -Filter rg.exe -File |
    Select-Object -First 1

& $codexRg.FullName --version
ripgrep 15.1.0

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.

ShadowLemoon · 1 month ago

I can reproduce this on Windows as well.

In the Codex shell, Get-Command rg resolves to:

``text
C:\Users\<user>\AppData\Local\Microsoft\WinGet\Links\rg.exe
``

Running rg --version without 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.exe successfully.

This further supports resolving Codex-managed dependencies using absolute paths, or ensuring the bundled tool directory takes precedence over user-controlled PATH entries.