Windows desktop Summary tab shows false GitHub CLI / PR status errors for WSL repos and logs git watcher ENOENT on .git paths #17991

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   on Apr 15, 2026
2. github-actions commented on Apr 15, 2026

   

   github-actionsBot

   on Apr 15, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex App refuses to see GitHub CLI - shows "Install GitHub CLI (gh) to create PRs #16778
   • Desktop "Create branch" fails with Wsl/Service/E_UNEXPECTED on Windows/WSL even though git succeeds #17961

   Powered by Codex Action
3. tompw89 commented on Apr 15, 2026

   

   tompw89

   on Apr 15, 2026

   Author

   More actions

   Draft prepared with Codex assistance; details verified by me.

   I reviewed the duplicate suggestions from the bot.

   • Codex App refuses to see GitHub CLI - shows "Install GitHub CLI (gh) to create PRs #16778 looks related to the false GitHub CLI detection family, but it is a different surface and different environment (macOS PR creation flow rather than Windows/WSL Summary tab state).
   • Desktop "Create branch" fails with Wsl/Service/E_UNEXPECTED on Windows/WSL even though git succeeds #17961 looks related to Windows/WSL desktop integration failures, but it is about branch creation (Wsl/Service/E_UNEXPECTED), not the Summary tab GitHub/PR-status path.

   So I do not believe this issue is a duplicate of either one.
4. eschulma commented on Apr 23, 2026

   

   eschulma

   on Apr 23, 2026

   More actions

   Yes, we have this too. There is a workaround -- make a symbolic link via PowerShell to point to your project.
5. TyceHerrman commented on May 7, 2026

   

   TyceHerrman

   on May 7, 2026

   More actions

   seeing similar behavior in desktop app on macos
6. Yuichiroh-Kobayashi commented on May 9, 2026

   

   Yuichiroh-Kobayashi

   on May 9, 2026

   More actions

   Draft prepared with Codex assistance; details verified by me.

   I am adding reproduction details here because this appears to match the visible Desktop symptom in this issue, rather than opening a new duplicate issue.

   I am seeing a very similar issue on Windows + WSL with Codex Desktop.

   Environment

   • OS/Runtime: Windows 11 host with WSL2
   • WSL distro: Ubuntu 24.04.4 LTS
   • Kernel: 6.6.87.2-microsoft-standard-WSL2
   • Repository path: /home/<redacted>/Dev/<repo>
   • Current branch: main
   • GitHub CLI: gh version 2.92.0
   • gh path: /usr/bin/gh
   • Git protocol: HTTPS
   • Codex Desktop version: 26.506.31421

   GUI symptom

   Codex Desktop keeps showing the Japanese equivalent of:

   Unable to fetch pull request status
   

   Specifically:

   プルリクエストの状態を取得できません
   

   Restarting Codex Desktop did not change the state.

   CLI evidence

   When the command is run with Codex network access allowed, GitHub CLI authentication succeeds:

   Logged in to github.com account <account>
   Git operations protocol: https
   Token scopes include repo
   

   Repository lookup also succeeds:

   {"defaultBranchRef":{"name":"main"},"nameWithOwner":"<owner>/<repo>"}

   gh pr status succeeds and reports that there is simply no PR associated with the current branch:

   Relevant pull requests in <owner>/<repo>
   
   Current branch
     There is no pull request associated with [main]
   
   Created by you
     You have no open pull requests
   
   Requesting a code review from you
     You have no pull requests to review
   

   gh pr view --json number,url,headRefName,baseRefName returns:

   no pull requests found for branch "main"
   

   Sandbox/network distinction

   In the normal Codex sandbox, gh auth status reports the token as invalid.

   With Codex network access allowed, the same gh auth status succeeds.

   So this does not look like a normal GitHub CLI setup problem. It looks like Codex Desktop may be surfacing either:

   1. a sandbox/network/auth reachability failure, or
   2. a normal “no PR for current branch” state,

   as a generic PR-status error.

   Expected behavior

   If the current branch simply has no associated pull request, the Desktop UI should show a normal empty state, for example:

   No pull request is associated with the current branch.
   

   If GitHub cannot be reached from the current sandbox/network context, the UI should distinguish that from:

   • gh not installed
   • gh not authenticated
   • no PR associated with the current branch
   • actual GitHub API failure

   Possibly related

   This may also overlap with the sandbox/network/auth false-negative issues discussed in #12996 and #21821, but the visible Desktop symptom here matches this issue most closely.

   Note: I am not assuming the same root cause as #21821, because this environment uses WSL Linux /usr/bin/gh and the Linux GitHub CLI config under /home/..., not the Windows Credential Manager / keyring path.
7. tompw89 commented on May 10, 2026

   

   tompw89

   on May 10, 2026

   Author

   More actions

   Adding one impact clarification plus fresh diagnostic evidence.

   This is not only a misleading Summary-tab error message. Because Desktop's git watcher is failing on WSL repo paths, repo-derived UI can become stale or incomplete. In practice that can make Desktop show false PR/GitHub status errors, fail to refresh branch/repo state, and potentially leave review/diff surfaces empty or out of date. The user experience is that a valid WSL Git workspace appears partially broken, even though Git and GitHub CLI work normally in the same environment.

   I also tested the suggested Windows symlink workaround on Codex Desktop 26.506.3741.0. It did not fix the watcher on this machine. Creating C:\home\tom\projects -> \\wsl$\Ubuntu\home\tom\projects made the Linux path visible to Windows, but Desktop's watcher failure changed from ENOENT to EISDIR.

   A standalone Windows Node test reproduced the same behaviour:

   • fs.watch() fails on the symlink path.
   • fs.watch() also fails on the direct \\wsl$ path.
   • fs.watchFile() succeeds on the same paths.

   That suggests the robust fix is not a path symlink. Desktop should avoid Windows fs.watch() for WSL-backed git paths, either by routing those watches through app-server fs/watch, or by falling back when local fs.watch() throws ENOENT or EISDIR.

   👍React with 👍1Reacted by Yuichiroh Kobayashi
8. tajemniktv commented on May 17, 2026

   

   tajemniktv

   on May 17, 2026

   More actions

   I started seeing that issue today for some reason. I was tinkering with config.toml, but nothing that would break github integration.

   Funny thing is, I can use "Commit" button and after using it, the "Open Pull Request" reports back as usual.
9. 0xdevalias commented on Jun 12, 2026

   

   0xdevalias

   on Jun 12, 2026

   More actions

   Cross-linking a macOS instance of the same misleading Summary-panel state:

   • Codex Desktop falsely reports "GitHub CLI unavailable" when shell environment loading times out #27740

   The underlying cause there is different from the WSL watcher failure described here. Codex Desktop's main-process shell environment import exceeds its 5-second timeout, leaving a minimal GUI PATH; gh --version then fails to resolve and the UI maps that directly to GitHub CLI unavailable.

   This provides another concrete case where the visible missing state is a generic downstream result rather than proof that GitHub CLI is actually absent. #27740 includes packaged-code and log evidence for that path.