Skip to content

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

Open
Open
Windows desktop shell exposes bundled rg.exe, but executing it fails with Access is denied#18666
Labels
appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@jianzhangg
jianzhangg
opened on Apr 20, 2026

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: 
    Get-Command rg | Format-List Name,CommandType,Source,Path,Version
  4. Observe that PowerShell resolves rg to:
    C:\Program Files\WindowsApps\OpenAI.Codex_26.415.1938.0_x64__2p2nqsd0c76g0\app\resources\rg.exe
  5. Run: 
    rg --version
  6. Observe the command fails immediately with Access is denied.
  7. Run the resolved absolute path directly: 
    & 'C:\Program Files\WindowsApps\OpenAI.Codex_26.415.1938.0_x64__2p2nqsd0c76g0\app\resources\rg.exe' --version
  8. Observe the same Access is denied failure.
  9. Repeat from an escalated shell.
  10. 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 Windows: bundled rg in Codex Desktop resolves on PATH but fails with Access Denied in integrated PowerShell #13542, but I am filing a separate report here with full template information and a complete Windows reproduction.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    on Apr 20, 2026

  2. github-actions commented on Apr 20, 2026

    @github-actions
    github-actionsBot
    on Apr 20, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. emanuele-novellino-en commented on Apr 20, 2026

    @emanuele-novellino-en
    emanuele-novellino-en
    on Apr 20, 2026

    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

  4. tomfleet commented on Apr 21, 2026

    @tomfleet
    tomfleet
    on Apr 21, 2026

    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?

  5. 17726 commented on Jul 12, 2026

    @17726
    17726
    on Jul 12, 2026

    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.

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

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions