Windows desktop shell exposes bundled rg.exe, but executing it fails with Access is denied
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 --versionrg --filesrg -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?
- Install and launch the Codex desktop app on Windows.
- Open a shell inside the Codex desktop environment.
- Run:
``powershell``
Get-Command rg | Format-List Name,CommandType,Source,Path,Version
- Observe that PowerShell resolves
rgto:
C:\Program Files\WindowsApps\OpenAI.Codex_26.415.1938.0_x64__2p2nqsd0c76g0\app\resources\rg.exe
- Run:
``powershell``
rg --version
- Observe the command fails immediately with
Access is denied. - Run the resolved absolute path directly:
``powershell``
& 'C:\Program Files\WindowsApps\OpenAI.Codex_26.415.1938.0_x64__2p2nqsd0c76g0\app\resources\rg.exe' --version
- Observe the same
Access is deniedfailure. - Repeat from an escalated shell.
- 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:
rgruns successfully from the Codex shell on Windows- Codex does not put an unusable
rgon 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-Commandandwhere-style resolution, but not actually launchable. - Local workaround on this machine is to avoid
rgentirely 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.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Confirmed on my machine.
I can reproduce the same issue in Codex Desktop on Windows.
What I verified:
where.exe rgshows 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 --versionworks when the standalone WinGet ripgrep is usedDirect 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:
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?
I reproduced this on the renamed ChatGPT desktop app as well.
Environment:
OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0C:\Program Files\WindowsApps\OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0\app\resources\rg.exe15.1.0Some additional findings:
Access is denied.rg.exehas theEncryptedattribute. Metadata-preserving copy operations such as PowerShellCopy-Itemand .NETFile.Copyfail on this source with an encryption-related error.~\.codex\tmp\arg0\codex-arg0...\rg.exeThat directory is already prepended to the child process
PATH. After materialization:Get-Command rg.exeresolved to the arg0 directoryrg --versionsucceededrg --filessucceededI also found the earlier OpenAI experiment in commit
3981bbf.It uses the same general location, but copies the executable with
std::fs::copyand silently ignores copy failures.I have prepared a small patch against the current
mainthat hardens that approach by:rg.exefor reading;NamedTempFilecreated in the arg0 directory;rg.exe;rg.exe;The focused
codex-arg0test suite passes on Windows (8/8), as do thescoped 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.