Windows app PR button falsely says GitHub CLI is not installed

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.

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.

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.

I am having the exact same issue!

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.

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

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.

I'm also seeing this on MacOS

Also seeing this on macOS.

I prepared a fix here:

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

Commit:
https://github.com/BeastNectus/codex/commit/ab3715001e60f3ddffea6e4dbb5efc9623c4d2b9

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

Also seeing this on macOS.

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.