Windows: bundled rg in Codex Desktop resolves on PATH but fails with Access Denied in integrated PowerShell

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

• #10090
• #9062

Powered by Codex Action

Is there any official response to this issue?
Codex Windows app is unusable right now

@azarenkova-git, just to confirm, this occurs when you attempt to invoke rg manually from within the app's built-in terminal? If so, why is that blocking you from using Codex Windows?

@etraut-openai Codex gives me the error that rg is not usable in this shell and falls back to PowerShell file search. Meanwhile, it works just fine in the VS Code extension. The rg bundled with the app is stored in C:/Program Files/WindowsApps which it is not able to access.

Can confirm

rg -n "GameThreadWaitForTask|STAT_GameIdleTime|Frame Sync Time|FrameEndSync|FFrameEndSync|Sync\(" Engine/Source/Runtime/RenderCore/Private/RenderingThread.cpp
ResourceUnavailable: 
Line |
   2 |  rg -n "GameThreadWaitForTask|STAT_GameIdleTime|Frame Sync Time|FrameE …
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Program 'rg.exe' failed to run: An error occurred trying to start process 'C:\Program Files\WindowsApps\OpenAI.Codex_26.311.2262.0_x64__2p2nqsd0c76g0\app\resources\rg.exe' with working directory 'D:\unrealengine5'. 拒绝访问。At line:2 char:1
+ rg -n "GameThreadWaitForTask|STAT_GameIdleTime|Frame Sync Time|FrameE …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.

error occurs while agent using rg.exe, just like apply_patch, they're no permission to execute

I hit the same issue and wanted to share what happened on my machine.

Environment:

• Codex Desktop on Windows
• rg initially resolved to the bundled binary under C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\rg.exe
• Running rg --version failed with Access is denied

What worked for me:

1. Installed ripgrep separately with:

winget install --id BurntSushi.ripgrep.MSVC -e

1. In the current shell, the newly installed rg.exe could be invoked directly by full path.
2. However, fresh Codex shell sessions still picked the bundled WindowsApps rg at first.
3. After restarting the Codex app, PATH was refreshed correctly and rg started resolving to the winget-installed binary instead of the bundled one.

So on my side, the practical fix was:

• install ripgrep separately
• restart Codex Desktop so the new PATH is picked up cleanly

That was enough; no permanent wrapper was needed in the end.

I had a similar issue with the same error message, I'm not sure if it had the same source though. I was able to fix it by adding the following to the custom instructions in the settings:

• When running shell commands on Windows, normalize workdir by stripping a leading \\?\ prefix before execution.

I hit the same issue and wanted to share what happened on my machine. Environment: Codex Desktop on Windows rg initially resolved to the bundled binary under C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\rg.exe Running rg --version failed with Access is denied What worked for me: 1. Installed ripgrep separately with: winget install --id BurntSushi.ripgrep.MSVC -e 2. In the current shell, the newly installed rg.exe could be invoked directly by full path. 3. However, fresh Codex shell sessions still picked the bundled WindowsApps rg at first. 4. After restarting the Codex app, PATH was refreshed correctly and rg started resolving to the winget-installed binary instead of the bundled one. So on my side, the practical fix was: install ripgrep separately * restart Codex Desktop so the new PATH is picked up cleanly That was enough; no permanent wrapper was needed in the end.

I can confirm that. I had the same problem (on two computers), and this solution worked right away.

I can also confirm that.

<img width="1180" height="100" alt="Image" src="https://github.com/user-attachments/assets/467204c4-c162-4850-bd0c-72e0d98e03bc" />

Setting the PATH variable didn't work for me.
But giving my user full access to the "resources" folder did the trick.
In my case, this is

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

I also get this very frequently, Codex falls back to PowerShell search.

I also get this very frequently, Codex falls back to PowerShell search.

You should really force it to use rg it is a much much smoother experience.
make sure its installed and in path ects.

i also added a line in the always promt use rg becouse else it wil sometimes not try that first, i think becouse somewhere its remembering that its not working or whatever.

I told codex to copy rg to apply_patch path, just working. some other PATH should work as well.

<img width="954" height="420" alt="Image" src="https://github.com/user-attachments/assets/e4c7b8e4-c03d-4dc5-a9ff-f1023065ec38" />

I also get this very frequently, Codex falls back to PowerShell search.

I get it whenever I start a session lol. What is OpenAI doing?

They're vibe coding.

On the other note, for me, administrative sandbox failed to set up and even
though I had given full access this is still happening

On Sat, 18 Apr 2026, 20:16 Sazid Al Bayazid @.***>
wrote:

albayazid left a comment (openai/codex#13542) <https://github.com/openai/codex/issues/13542#issuecomment-4274199652> I also get this very frequently, Codex falls back to PowerShell search. I get it whenever I start a session lol. What is OpenAI doing? — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/13542?email_source=notifications&email_token=ATD6MCHPYNNJ5GOGEIYVDA34WOZ6JA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGQYTSOJWGUZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4274199652>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATD6MCBLYGFWVWOZRNHR2VD4WOZ6JAVCNFSM6AAAAACWHRINOSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENZUGE4TSNRVGI> . You are receiving this because you commented.Message ID: @.***>

Reproduced here as well on a newer Windows desktop build.

Environment:

• Codex desktop app bundle path resolves rg to C:\Program Files\WindowsApps\OpenAI.Codex_26.415.1938.0_x64__2p2nqsd0c76g0\app\resources\rg.exe
• Windows: Microsoft Windows NT 10.0.26100.0
• PowerShell: 7.6.0

Observed behavior inside the Codex desktop shell:

• Get-Command rg succeeds and points to the packaged rg.exe
• rg --version fails immediately with Access is denied
• invoking the absolute path to the same rg.exe also fails with Access is denied
• I also reproduced the same failure in an escalated shell from Codex, so this does not look like a simple non-elevated PATH problem

Representative 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' ... Access is denied.

Workaround on this machine is to avoid rg entirely and use PowerShell-native search commands instead, but that obviously breaks the normal recommended workflow.

I the same problem in both the VS Code extension and the stand-alone Codex app. Every conversation starts with this error.

Installing RipGrep separately does not work around for me:

> Codex, please run rg with --version for testing purposes rg --version did not run successfully here. PowerShell resolves rg to: C:\Users\REDACTED\AppData\Local\Microsoft\WinGet\Links\rg.exe That path is a symbolic link to: C:\Users\REDACTED\AppData\Local\Microsoft\WinGet\Packages\BurntSushi.ripgrep.MSVC_Microsoft.Winget.Source_8wekyb3d8bbwe\ripgrep-15.1.0-x86_64-pc-windows-msvc\rg.exe What happened: Invoking rg via the WinGet link failed with: No application is associated with the specified file for this operation Invoking the real binary directly failed with: Access is denied

I can run 'rg' fine from a PowerShell myself.

This is still an on going issue it seems and still exists

It very much is

This happens to me when I give the Codex desktop app "Full access," which supports the original post's assertion. It's been extremely annoying.

Hello everyone I'm pretty sure this is more of a user side config issue.
I'm guessing most of the people here have PowerShell profiles ects.

Make sure that rg is in the path of the profile that codex is using.
Codex's terminal might stop the profile init if its unable to run something on there.

Just make sure that doesnt happen and your custom install of rg is in the path.

This seems like an ACL issue. I randomly discovered today that I had a Windows 11 machine where rg worked correctly in Codex. After a lot of investigation, running this on the non-working machine:

icacls "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI"

shows that the CodexSandBoxUsers group does not have any permissions set. This directory is where a copy of rg.exe lives. On my working machine, that command showed CodexSandBoxUsers having the read/execute permissions, which explains why rg worked.

Adding CodexSandBoxUsers Read/Execute on the broken machine:

icacls "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI" /grant 'CodexSandboxUsers:(OI)(CI)(RX)' /T

fixed the issue and allowed Codex to run rg. I have NO idea how durable that workaround is, but it worked. I couldn't even begin to explain why of the three Windows 11 machines I have with Codex on them, one of them had the ability to use rg correctly.

Further investigation shows an easier fix is to rerun the Windows sandbox setup process. I was able to trigger this by deleting ``%USERPROFILE%\.codex\config.toml``.

Upon selecting to use the elevated sandbox mode, ACEs were applied across various items in %USERPROFILE%, including rg.exe located in ``%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI``.

This seems a better way at going about it as opposed to applying an explicit ACE to that location.

Further investigation shows an easier fix is to rerun the Windows sandbox setup process. I was able to trigger this by deleting %USERPROFILE%\.codex\config.toml. Upon selecting to use the elevated sandbox mode, ACEs were applied across various items in %USERPROFILE%, including rg.exe located in %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI. This seems a better way at going about it as opposed to applying an explicit ACE to that location.

By elevated sandbox mode, do you mean "full access" mode? Did you just switched to it and switched back to default sandbox mode without submitting anything?

By elevated sandbox mode, do you mean "full access" mode? Did you just switched to it and switched back to default sandbox mode without submitting anything?

Naw I mean when you start up Codex for the first time or without a top-level config.toml on Windows it asks if you want to setup the Windows Sandbox. This sets the sandbox flag in that top-level config.toml:

[windows]
sandbox = "elevated"

and that process seems to trigger setting all the appropriate ACEs.

> By elevated sandbox mode, do you mean "full access" mode? Did you just switched to it and switched back to default sandbox mode without submitting anything? Naw I mean when you start up Codex for the first time or without a top-level config.toml on Windows it asks if you want to setup the Windows Sandbox. This sets the sandbox flag in that top-level config.toml: `` [windows] sandbox = "elevated" `` and that process seems to trigger setting all the appropriate ACEs.

Ah I see, but sadly that didn't do the trick for me. Then I tried the

icacls "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI" /grant 'CodexSandboxUsers:(OI)(CI)(RX)' /T

command, and it worked. Thanks!

Glad to hear! To be clear, setting that flag in the file manually didn't trigger the process. I had to force Codex to ask me to re-setup the Windows Sandbox. Codex appears to do more than just set that "elevated" flag in config.toml when setting up Windows Sandbox.

Yes I also did it like that, first deleted the config, then I opened the codex which trigged the sandbox setup prompt above the chat window. But in the end it was still unable to use rg in the sandbox.

Interesting. Good to know manually setting the ACE is still needed.

Confirming the ACL workaround fixed this for me.

Before fix:

• rg --version inside Codex failed with Access is denied
• rg resolved to C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\rg.exe
• Re-running Windows sandbox setup showed “sandbox ready” and set the windows.sandbox: elevated (paraphrasing ofc) in config.toml but it did not fix the issue.

The ACL was missing CodexSandboxUsers on $env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI

This fixed it:

icacls "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI" /grant 'CodexSandboxUsers:(OI)(CI)(RX)' /T

After restarting Codex, rg --version works inside the sandbox and Get-Command rg now resolves to:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\rg.exe

So at least on my machine, sandbox setup reported success but did not apply the needed ACE.

icacls "%AppData%\..\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI" /grant "CodexSandboxUsers:(OI)(CI)(RX)" /T
CMD version instead of PowerShell.

OR an actual thing that actually do really yes works:
Start ELEVATED Explorer.exe
C:\Program Files\WindowsApps\OpenAI.Codex_26.422.3464.0_x64__2p2nqsd0c76g0\app
right click resources-security-advanced
take ownership
close
right click resources-security-advanced
add
add your user with full control
click also thing thingy
<img width="527" height="24" alt="Image" src="https://github.com/user-attachments/assets/19f97972-d606-41cf-9802-ed13d86e9489" />
click apply ok

I hit a related but slightly different variant of this issue on the Windows Store/MSIX Codex app.

Environment:

• Codex app installed from Microsoft Store
• Package path looked like:

C:\Program Files\WindowsApps\OpenAI.Codex_26.422.8496.0_x64__2p2nqsd0c76g0\...

• rg --version inside Codex failed with Access is denied
• rg was resolving to:

C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\rg.exe

In my case, the ACL workaround mentioned above was not the missing piece. This path already had CodexSandboxUsers read/execute:

icacls "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI"

showed:

<machine>\CodexSandboxUsers:(I)(OI)(CI)(RX)

The actual problem was that Codex was injecting this path into PATH:

%LOCALAPPDATA%\OpenAI\Codex\bin

but that directory did not exist.

The working Codex-local binaries were actually here:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin

That directory contained:

codex.exe
codex-command-runner.exe
codex-windows-sandbox-setup.exe
node.exe
node_repl.exe
rg.exe

Fix/workaround:

New-Item -ItemType Directory -Force -Path "$env:LOCALAPPDATA\OpenAI\Codex"

New-Item `
  -ItemType Junction `
  -Path "$env:LOCALAPPDATA\OpenAI\Codex\bin" `
  -Target "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin"

After restarting Codex:

where.exe rg

resolved first to:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\rg.exe

and:

rg --version

worked:

ripgrep 15.1.0

I also verified the WindowsApps and LocalCache binaries were byte-for-byte identical by SHA256, so the issue was not a bad binary. It was path/layout/packaging:

WindowsApps\...\app\resources\rg.exe
LocalCache\Local\OpenAI\Codex\bin\rg.exe

were the same binary, but Windows blocked direct execution from WindowsApps.

So there may be two separate failure modes here:

1. CodexSandboxUsers is missing RX on %LOCALAPPDATA%\Packages\OpenAI.Codex_...\LocalCache\Local\OpenAI
2. %LOCALAPPDATA%\OpenAI\Codex\bin is injected into PATH but was never created or linked to the actual MSIX LocalCache bin directory

The second one was the issue on my machine.

I’m seeing a related but slightly different failure mode on a fresh Codex Desktop install.

Environment

• Windows
• Fresh Codex Desktop install
• Codex package observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.429.2026.0_x64__2p2nqsd0c76g0
• PowerShell resolves to the WinGet/MSIX package: C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.1.0_x64__8wekyb3d8bbwe\pwsh.exe

Integrated terminal behavior

In the Codex integrated terminal:

Get-Command rg -All

returns:

Get-Command: The term 'rg' is not recognized...

So in my integrated terminal, Codex's bundled app\resources directory does not appear to be on PATH.

Agent/tool-runner behavior

However, from the Codex agent shell/tool runner, rg resolves to:

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

and attempting to run it fails with:

Program 'rg.exe' failed to run:
An error occurred trying to start process
'C:\Program Files\WindowsApps\OpenAI.Codex_26.429.2026.0_x64__2p2nqsd0c76g0\app\resources\rg.exe'
Access is denied.

where.exe rg from the tool-runner context showed:

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

Sandbox behavior

The sandbox also appears to fail before the requested command starts. Even simple sandboxed commands such as:

Get-Location
Get-Command rg -ErrorAction SilentlyContinue
rg --version
Get-ChildItem -Force
whoami

failed with:

windows sandbox: runner error: CreateProcessAsUserW failed: 5

That suggests this is not only an rg.exe issue. The sandbox process launcher itself is hitting Windows Access is denied.

Binary validation

Copying the bundled rg.exe out of WindowsApps into the workspace made the same binary runnable outside the sandbox:

ripgrep 15.1.0 (rev af60c2de9d)

features:+pcre2
simd(compile):+SSE2,-SSSE3,-AVX2
simd(runtime):+SSE2,+SSSE3,+AVX2

PCRE2 10.45 is available (JIT is available)

So the binary itself is valid. The failure appears tied to executing it from the MSIX/WindowsApps package location and/or launching through the sandbox token.

ACL observation

The bundled rg.exe under the Codex package has ACL entries including app/package-identity-conditioned permissions. Owner/group are NT AUTHORITY\SYSTEM, and there are conditional entries for the Codex package identity.

This seems consistent with WindowsApps/MSIX execution restrictions: the Codex app package can contain the executable, but child processes launched from the integrated terminal or restricted sandbox token may not have the package identity required to execute package resources directly.

Key difference from the original report

In the original report, the integrated terminal had Codex’s bundled app\resources directory on PATH, so Get-Command rg -All found rg.exe and then execution failed.

In my fresh install, the integrated terminal does not have rg on PATH, but the Codex agent/tool runner still does. So there appear to be at least two inconsistent states:

State A:
Integrated terminal PATH includes Codex app\resources.
rg resolves but fails with Access denied.

State B:
Integrated terminal PATH does not include Codex app\resources.
Agent/tool-runner PATH does include Codex app\resources.
rg resolves there but fails with Access denied.

seems like Codex is unable to access every .exe in the resources folder, not just rg:

codex.exe                       Access is denied
codex-command-runner.exe        Access is denied
codex-windows-sandbox-setup.exe Access is denied
node.exe                        Access is denied
node_repl.exe                   Access is denied
rg.exe                          Access is denied

In my case, the LocalCache ACL already grants CodexSandboxUsers read/execute, and the cached binaries run. rg failed for me because the PATH resolved to %LOCALAPPDATA%\OpenAI\Codex\bin

but that directory did not exist, so rg resolution fell through to the blocked WindowsApps resources copy. Creating that directory and copying rg.exe fixed it for me, though it's obviously hacky.

I can reproduce this on a newer Windows Codex Desktop build, and it appears to be the same WindowsApps/MSIX helper-resolution issue rather than a missing ripgrep install.

Environment:

• Codex App package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Windows / PowerShell agent shell launched from Codex Desktop
• User does not have a separate ripgrep install in Scoop shims at the moment

What happens:

Get-Command rg -All
rg --version

rg resolves to:

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

and rg --version fails with:

Program 'rg.exe' failed to run: An error occurred trying to start process ... Access is denied / 拒绝访问

Additional local diagnostics:

• The Codex app\resources path is not in the User PATH or Machine PATH. It appears only in the Codex-launched process PATH.
• The same directory's executables (codex.exe, node.exe, rg.exe, etc.) have the Encrypted attribute.
• Launching the packaged codex.exe directly from the same app\resources directory also fails with Access Denied.
• %LOCALAPPDATA%\OpenAI\Codex\bin exists, but it currently contains only a .staging-* directory and no rg.exe, node.exe, codex.exe, etc.
• %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin does not exist on this machine.

So this local state looks like the per-user helper bin did not finish materializing/syncing, and the agent/tool PATH then falls through to the protected WindowsApps package resources copy. That copy is discoverable and hashable, but not executable from the spawned shell/tool context.

Practical workaround remains installing a separate ripgrep earlier on PATH, e.g. with Scoop, then restarting Codex Desktop so the refreshed PATH resolves rg before the blocked WindowsApps copy. But the product-side issue seems to be that Codex exposes a non-executable packaged helper path, or fails to populate/use the intended per-user helper bin first.