Windows desktop shell exposes bundled rg.exe, but executing it fails with Access is denied

Open 💬 4 comments Opened Apr 20, 2026 by jianzhangg
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Observed packaged app version from the resolved bundled executable path:
OpenAI.Codex_26.415.1938.0_x64__2p2nqsd0c76g0

I could not get a separate value from the Windows package query, but this is the exact bundle path that Get-Command rg resolves to inside the Codex desktop shell.

What subscription do you have?

The local Codex auth configuration is currently in API key mode (auth_mode=apikey). I am not using a separate Codex subscription plan from within the app UI for this repro.

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

Inside the Codex desktop shell on Windows, rg appears to be available, but it is not actually executable.

Get-Command rg succeeds and resolves to the bundled executable:
C:\Program Files\WindowsApps\OpenAI.Codex_26.415.1938.0_x64__2p2nqsd0c76g0\app\resources\rg.exe

But any attempt to execute it fails immediately with an access error:

Program 'rg.exe' failed to run: An error occurred trying to start process 'C:\Program Files\WindowsApps\OpenAI.Codex_26.415.1938.0_x64__2p2nqsd0c76g0\app\resources\rg.exe' with working directory 'C:\code\doc'. Access is denied.

I reproduced the same failure for:

  • rg --version
  • rg --files
  • rg -n -- "--serve" C:\code\doc\script\codex_token_report\codex_token_report.py
  • directly invoking the absolute executable path shown by Get-Command rg

I also reproduced the same failure when running the same command from an escalated shell launched through Codex tooling, so this does not look like a simple non-elevated PATH problem.

This is especially confusing because the normal agent guidance recommends using rg, and the shell environment makes it look installed and available.

What steps can reproduce the bug?

  1. Install and launch the Codex desktop app on Windows.
  2. Open a shell inside the Codex desktop environment.
  3. Run:

``powershell
Get-Command rg | Format-List Name,CommandType,Source,Path,Version
``

  1. Observe that PowerShell resolves rg to:

C:\Program Files\WindowsApps\OpenAI.Codex_26.415.1938.0_x64__2p2nqsd0c76g0\app\resources\rg.exe

  1. Run:

``powershell
rg --version
``

  1. Observe the command fails immediately with Access is denied.
  2. Run the resolved absolute path directly:

``powershell
& 'C:\Program Files\WindowsApps\OpenAI.Codex_26.415.1938.0_x64__2p2nqsd0c76g0\app\resources\rg.exe' --version
``

  1. Observe the same Access is denied failure.
  2. Repeat from an escalated shell.
  3. Observe the same result.

What is the expected behavior?

If Codex exposes rg on PATH inside its desktop shell, the bundled rg.exe should be executable.

At minimum, one of these should be true:

  • rg runs successfully from the Codex shell on Windows
  • Codex does not put an unusable rg on PATH
  • Codex detects this packaging/permission problem and falls back to another supported search tool

Additional information

  • PowerShell version: 7.6.0
  • The executable is visible enough for Get-Command and where-style resolution, but not actually launchable.
  • Local workaround on this machine is to avoid rg entirely and use PowerShell-native search (Get-ChildItem, Select-String, Get-Content), but that breaks the expected workflow and tool recommendations.
  • This may be related to the bundled executable living under C:\Program Files\WindowsApps\..., but from the user side the core problem is that Codex exposes a command that cannot be executed.
  • Possibly related to issue #13542, but I am filing a separate report here with full template information and a complete Windows reproduction.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

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

  • #17972

Powered by Codex Action

emanuele-novellino-en · 4 months ago

Confirmed on my machine.

I can reproduce the same issue in Codex Desktop on Windows.

What I verified:

  • where.exe rg shows both my standalone WinGet ripgrep and the bundled Codex copies under:

C:\Program Files\WindowsApps\OpenAI.Codex_26.415.4716.0_x64__2p2nqsd0c76g0\app\resources\

  • rg --version works when the standalone WinGet ripgrep is used
  • direct execution of the bundled binaries fails with Access denied

Direct repro:
& "C:\Program Files\WindowsApps\OpenAI.Codex_26.415.4716.0_x64__2p2nqsd0c76g0\app\resources\rg.exe" --version
-> ResourceUnavailable / Access denied

& "C:\Program Files\WindowsApps\OpenAI.Codex_26.415.4716.0_x64__2p2nqsd0c76g0\app\resources\rg" --version
-> ResourceUnavailable / Access denied

Conclusion:

  • system ripgrep is healthy
  • PowerShell shell resolution is healthy
  • bundled Codex ripgrep is present but not executable
  • the problem appears to be in the Codex Desktop packaged/bundled runtime on Windows
tomfleet · 4 months ago

As far as I can make out, this is expected?

It's an exec located outside of syspath, and outside of the project dir/workspace folder, so, it's counted as a blocked action as per what I can interpret from the prompts included in the copilot JS bundle?

17726 · 1 month ago

I reproduced this on the renamed ChatGPT desktop app as well.

Environment:

  • Package: OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
  • Bundled executable:

C:\Program Files\WindowsApps\OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0\app\resources\rg.exe

  • Bundled ripgrep version: 15.1.0

Some additional findings:

  1. The file is readable and its ACL includes read/execute permissions, but Windows still rejects direct process creation with Access is denied.
  1. The packaged rg.exe has the Encrypted attribute. Metadata-preserving copy operations such as PowerShell Copy-Item and .NET File.Copy fail on this source with an encryption-related error.
  1. Opening the source as a byte stream and writing it into a newly created file succeeds. The destination does not inherit the package encryption metadata and can be executed normally.
  1. I tested materializing it into the existing per-session arg0 directory:

~\.codex\tmp\arg0\codex-arg0...\rg.exe

That directory is already prepended to the child process PATH. After materialization:

  • Get-Command rg.exe resolved to the arg0 directory
  • rg --version succeeded
  • rg --files succeeded

I also found the earlier OpenAI experiment in commit
3981bbf.
It uses the same general location, but copies the executable with
std::fs::copy and silently ignores copy failures.

I have prepared a small patch against the current main that hardens that approach by:

  • opening the bundled sibling rg.exe for reading;
  • streaming it into a NamedTempFile created in the arg0 directory;
  • flushing and atomically persisting it as rg.exe;
  • warning on unexpected materialization failures;
  • safely skipping installations without a sibling rg.exe;
  • adding regression tests.

The focused codex-arg0 test suite passes on Windows (8/8), as do the
scoped Clippy and formatting checks.

Since external pull requests require a maintainer invitation, would the
maintainers prefer to incorporate this finding internally, or would you
welcome a focused PR that ports and hardens the approach from 3981bbf?

I can open the prepared PR if invited.