Skip to content

Windows app PR button falsely says GitHub CLI is not installed #13689

Closed
Closed
Windows app PR button falsely says GitHub CLI is not installed#13689
Labels
GitappIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@Dj-Shortcut
Dj-Shortcut
opened on Mar 6, 2026

Summary

The "Create PR" button says GitHub CLI (gh) must be installed, but gh is already fully available inside the app environment.

What version of Codex is running?

Desktop app on Windows (current as of March 6, 2026)

What platform is your computer?

Windows 11

Steps to reproduce

  1. Open the Codex desktop app on Windows
  2. Open a repo with git + GitHub configured
  3. Hover or use the PR button
  4. The UI says GitHub CLI must be installed

Expected behavior

The PR button should recognize the installed gh CLI and allow PR creation.

Actual behavior

The UI says GitHub CLI is not installed.

Verification done inside the app terminal

  • gh --version works
  • gh auth status works
  • C:\Windows\System32\where.exe gh returns C:\Program Files\GitHub CLI\gh.exe

Conclusion

This appears to be a stale or incorrect gh-detection bug in the PR button UI, not a local installation issue.

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 Mar 6, 2026

  2. etraut-openai commented on Mar 6, 2026

    @etraut-openai
    etraut-openai
    on Mar 6, 2026
    Contributor

    Are you running the app from within WSL or in native Windows mode? If it's within WSL, I think it won't be able to see the gh installed in Windows\System32.

  3. Dj-Shortcut commented on Mar 7, 2026

    @Dj-Shortcut
    Dj-Shortcut
    on Mar 7, 2026
    Author

    Are you running the app from within WSL or in native Windows mode? If it's within WSL, I think it won't be able to see the gh installed in Windows\System32.

    I verified:

    Shell is C:\WINDOWS\system32\cmd.exe
    %WSL_DISTRO_NAME% is not set
    gh is visible on PATH as C:\Program Files\GitHub CLI\gh.exe
    gh --version returns 2.87.3 from February 23, 2026
    So this is not a WSL-vs-Windows visibility issue. The more likely problem is the app’s own detection logic or how it launches the check. One relevant detail: when commands are started with the \?\C:... style working directory, cmd.exe reports that path as unsupported and falls back to the Windows directory. That may be interfering with the app’s environment handling.

  4. Dj-Shortcut commented on Mar 7, 2026

    @Dj-Shortcut
    Dj-Shortcut
    on Mar 7, 2026
    Author

    Small additional data point in case it helps the detection logic:

    where gh
→ C:\Program Files\GitHub CLI\gh.exe

echo %PATH%
→ ...;C:\Program Files\GitHub CLI\;...

    So gh is resolvable through PATH from the same shell environment.
    If the app checks availability via spawn/which/where, it should normally succeed.

    Let me know if there is a specific command the app uses for detection and I can test that as well.

  5. kjin2020 commented on Mar 31, 2026

    @kjin2020
    kjin2020
    on Mar 31, 2026

    I am having the exact same issue!

  6. lejmer commented on Apr 2, 2026

    @lejmer
    lejmer
    on Apr 2, 2026

    I have the same issue. I even had the agent try it so I know it's available to the agent in the environment that the agent uses (I run the Windows version of the app and it is using WSL for the agent environment). The agent ran the command and got:

    $ gh --version

gh version 2.45.0 (2025-07-18 Ubuntu 2.45.0-1ubuntu0.3)
https://github.com/cli/cli/releases/tag/v2.45.0

    and if I try it in my own terminal (inside of the Codex app, which in my case is powershell):

    PS C:\Users\<redacted>\source\repos\<redacted>> gh --version
gh version 2.87.3 (2026-02-23)
https://github.com/cli/cli/releases/tag/v2.87.3

    So the cli is available on both systems which points to a Codex app bug.

  7. Dj-Shortcut commented on Apr 3, 2026

    @Dj-Shortcut
    Dj-Shortcut
    on Apr 3, 2026
    Author

    I traced this to a likely Windows-specific codex-app-server command/exec cwd-normalization issue.

    I prepared a narrow patch on my fork here:

    • Dj-Shortcut:fix/windows-gh-verbatim-cwd
    • commit: 813e51790

    What it changes:

    • normalizes Windows verbatim cwd values like \\?\C:\... before native command/exec startup
    • adds a Windows-only regression test
    • adds debug logging when a verbatim Windows cwd gets rewritten

    Relevant files:

    • codex-rs/app-server/src/codex_message_processor.rs
    • codex-rs/app-server/src/command_exec.rs

    What I verified locally:

    • the new regression test passes
    • the patch is very small and limited to app-server command/exec cwd normalization
    • I was able to build both a pre-fix and patched codex-app-server locally

    Important limitation:

    • I found a plausible open-source failure seam in codex-app-server, but I have not proven that the desktop app’s GitHub CLI / PR warning path actually goes through this exact route

  8. Dj-Shortcut commented on Apr 6, 2026

    @Dj-Shortcut
    Dj-Shortcut
    on Apr 6, 2026
    Author

    After spending more time with Git/GitHub, I think my original diagnosis may have been too strong.

    What I can confirm:

    • gh is available in the app terminal
    • gh auth status works
    • the UI message is potentially misleading

    What I can no longer confidently claim:

    • that this is definitely a gh-installation/detection bug

    It now seems possible the real issue is that the GUI PR flow had nothing valid to compare / open a PR against, while the app surfaced a generic “GitHub CLI is not installed” message instead.

    So the core problem may be incorrect or overly generic UI messaging, rather than actual missing CLI installation.

  9. aditzel commented on Apr 13, 2026

    @aditzel
    aditzel
    on Apr 13, 2026

    I'm also seeing this on MacOS

  10. edinabazi commented on Apr 15, 2026

    @edinabazi
    edinabazi
    on Apr 15, 2026

    Also seeing this on macOS.

  11. ambrosino-oai
    added
    Git
    on Apr 24, 2026

  12. johnmamanao commented on Apr 25, 2026

    @johnmamanao
    johnmamanao
    on Apr 25, 2026

    I prepared a fix here:

    https://github.com/BeastNectus/codex/tree/fix/windows-command-exec-cwd-normalization

    Commit:
    johnmamanao@ab37150

    Summary:

    • normalizes Windows verbatim cwd paths like \\?\C:\... before native command/exec process startup
    • adds a Windows regression test

    Validation:

    • cargo fmt --manifest-path codex-rs\Cargo.toml --package codex-app-server
    • cargo test --manifest-path codex-rs\Cargo.toml -p codex-app-server --lib normalize_command_exec_cwd_simplifies_windows_verbatim_paths

  13. KTMarc commented on May 4, 2026

    @KTMarc
    KTMarc
    on May 4, 2026

    Also seeing this on macOS.

  14. Dj-Shortcut commented on May 5, 2026

    @Dj-Shortcut
    Dj-Shortcut
    on May 5, 2026
    Author

    Update: the PR button is working for me now.

    The only local change I remember making was creating/refreshing a GitHub PAT a few days ago, but I cannot confidently reproduce the before/after state. It is possible the original “GitHub CLI is not installed” message was masking an auth/token-state problem rather than an actual missing-gh problem.

    I’ll leave this note here in case it helps debugging, but I can’t currently reproduce the issue anymore.

  15. Dj-Shortcut
    closed this as completedon May 6, 2026
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

    GitappIssues 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