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

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

• #16778
• #17961

Powered by Codex Action

Draft prepared with Codex assistance; details verified by me.

I reviewed the duplicate suggestions from the bot.

• #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).
• #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.

Yes, we have this too. There is a workaround -- make a symbolic link via PowerShell to point to your project.

seeing similar behavior in desktop app on macos

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.

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.

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.

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

• #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.