What version of Codex CLI is running?

0.122.0

What subscription do you have?

For Business

Which model were you using?

gpt-5.4

What platform is your computer?

Windows 11, x64

What terminal emulator and version are you using (if applicable)?

PowerShell

What issue are you seeing?

On native Windows, Codex cannot reliably execute rg (ripgrep) from standard PATH locations, even when rg works normally outside Codex.

In my case, rg.exe is available via WinGet in:

%LOCALAPPDATA%\Microsoft\WinGet\Links

Outside Codex, this is fine. Inside Codex native Windows, access to that location appears to be denied by the sandbox, which means Codex cannot use rg from a standard user-level install location.

This is especially painful because Codex seems to rely heavily on rg for search/file discovery, so this is not just a generic external-tool issue — it breaks core behavior.

Environment

• OS: Windows
• Codex: native Windows mode
• rg installed and usable outside Codex
• rg.exe available through WinGet alias path under %LOCALAPPDATA%\Microsoft\WinGet\Links

Problem

Inside Codex, attempting to inspect the WinGet Links directory fails even though it exists and is accessible outside Codex.

Example from inside Codex:

Get-ChildItem -Path C:\Users\<username>\AppData\Local\Microsoft\WinGet\Links

Output:

Get-ChildItem:
Line |
   2 |  Get-ChildItem -Path C:\Users\<username>\AppData\Local\Microsoft\WinGet\Li …
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Access to the path 'C:\Users\<username>\AppData\Local\Microsoft\WinGet\Links' is denied.
Get-ChildItem:
Line |
   2 |  Get-ChildItem -Path C:\Users\<username>\AppData\Local\Microsoft\WinGet\Li …
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\Users\<username>\AppData\Local\Microsoft\WinGet\Links' because it does not exist.

Outside Codex, the same location is accessible and rg works normally.

So this appears to be a Codex native Windows sandbox/path-resolution issue rather than a broken rg install.

Why this deserves a dedicated issue

This is narrower than a general “allow extra folders in the Windows sandbox” request.

rg seems to be a core tool that Codex itself prefers to use for search/file operations, so inability to execute rg from a normal Windows user install location has an outsized impact on Codex usability.

From a user perspective, native Windows Codex becomes unreliable even though:

• rg is installed correctly
• PATH works outside Codex
• the executable is in a standard per-user tool location

What steps can reproduce the bug?

Repro steps

1. On Windows, install Codex and ripgrep via WinGet so rg works in a regular shell

2. Confirm outside Codex:

   where.exe rg rg --version Get-ChildItem "$env:LOCALAPPDATA\Microsoft\WinGet\Links"

3. Start Codex in native Windows mode

4. Run:

   where.exe rg rg --version Get-ChildItem "$env:LOCALAPPDATA\Microsoft\WinGet\Links"

5. Observe that inside Codex, access to the WinGet Links path is denied or the path appears not to exist

What is the expected behavior?

Expected behavior

One of the following should work reliably in native Windows mode:

1. Codex can execute rg from standard PATH/user install locations such as %LOCALAPPDATA%\Microsoft\WinGet\Links
2. Codex ships a bundled rg that is always executable in its own Windows environment
3. Codex gracefully falls back between bundled rg and PATH rg without sandbox-related failures
4. Codex includes standard Windows user-level executable alias locations in its default readable/executable allowlist

Actual behavior

Codex native Windows appears unable to access %LOCALAPPDATA%\Microsoft\WinGet\Links, so it cannot reliably discover or execute rg from there.

Additional information

Notes

This seems related to Windows sandboxing / path allowlisting rather than to WinGet itself.

It may also be related to the existing Windows rg issues around bundled executables and WindowsApps, but this report is specifically about the inability to use a correctly installed PATH rg from a standard WinGet alias location.

Suggested fix

Please make native Windows Codex reliably able to use rg, since it appears to be part of Codex’s normal operating model.

Concrete options:

• add %LOCALAPPDATA%\Microsoft\WinGet\Links to the default Windows readable/executable roots
• explicitly special-case rg
• improve fallback behavior when bundled rg is inaccessible
• document how to grant this path for command discovery/execution if that is the intended model

Impact

This makes native Windows significantly less usable, because one of Codex’s key search tools cannot be relied on even when installed correctly on the host machine.