PR widget: GitHubPrManager drops --repo when session cwd is a non-git parent dir

Resolved 💬 2 comments Opened May 29, 2026 by taha-decklaration Closed Jun 1, 2026

PR widget: gh pr view call drops --repo when session cwd is a non-git parent directory

Claude Code Desktop version: 1.8555.2.0 (also reproduced in 1.8089.1.0)
OS: Windows 11 Pro 10.0.26200
gh version: verified working (gh pr view <num> --repo <owner>/<repo> succeeds from any cwd)

Symptom

Each session's PR widget shows: "Pull request status couldn't be checked and may be out of date." The cached PR state is still displayed, but no refresh succeeds.

Reproduction

  1. Have a parent folder that is not a git repo but contains multiple sibling git repos. Example layout:

``
D:\Decklaration\ ← not a git repo
├─ One-Now-Backend\ ← origin = 1-Now/One-Now-Backend
├─ One-Now-Frontend\ ← origin = 1-Now/One-Now-Frontend
└─ Template-1Now-FE\ ← origin = 1-Now/Template-1Now-FE
``

  1. Start a Claude Code Desktop session with cwd = D:\Decklaration.
  2. From inside that session, push branches and open PRs in any of the sibling repos. Claude Code Desktop correctly detects them and stores them in the session's prs[] array, e.g.:

``json
{
"prNumber": 288,
"url": "https://github.com/1-Now/One-Now-Backend/pull/288",
"repo": "1-Now/One-Now-Backend",
"branch": "fix-1now-1101-section-dedupe",
"baseRef": "development",
"state": "OPEN"
}
``

  1. Wait for the periodic PR refresh. Every call fails.

Diagnosis

%APPDATA%\Claude\logs\main.log shows the manager invoking gh pr view/gh pr checks without --repo, even though each prs[] entry carries a repo field:

2026-05-29 10:24:45 [info] LocalSessions.getPrChecks: cwd=D:\Decklaration, prNumber=288, repo=<none>
2026-05-29 10:24:45 [info] LocalSessions.getPrChecks: cwd=D:\Decklaration, prNumber=29, repo=<none>
2026-05-29 10:24:45 [info] LocalSessions.getPrChecks: cwd=D:\Decklaration, prNumber=93, repo=<none>
2026-05-26 22:03:17 [error] [GitHubPrManager] Failed to get PR checks: gh pr checks timed out
2026-05-26 22:03:18 [error] [GitHubPrManager] Failed to get PR state for branch: gh pr view timed out

Note the repo=<none> even though the session JSON has prs[].repo populated. Because cwd=D:\Decklaration isn't a git repo, gh pr view 288 errors with fatal: not a git repository (or any of the parent directories): .git. In older builds the same call hung until the manager's 4-second timeout fired.

Verification

From the same cwd=D:\Decklaration:

> gh pr view 288 --json state,number
failed to run git: fatal: not a git repository (or any of the parent directories): .git
exit 1

> gh pr view 288 --repo 1-Now/One-Now-Backend --json state,number
{"number":288,"state":"OPEN"}
exit 0

The fix exists in the data; it just isn't being threaded through.

Why workarounds don't work

  • git init D:\Decklaration with a single origin silently returns the wrong PR for cross-repo numbers. Tested: PR #47 in 1-Now/One-Now-Backend is an unrelated "location error fixes" PR; PR #47 in 1-Now/One-Now-Frontend is "fix(website-builder): stop destructive empty-string writes on Logo & Favicon". With origin=Backend, gh pr view 47 would return the wrong PR and the widget would overwrite cached Frontend state with Backend data.
  • Clearing the cached prs[] removes the warning at the cost of losing the widget's value entirely.
  • A single session here legitimately tracks PRs across 3 repos, so there is no single correct origin to set on the parent dir.

Suggested fix

In GitHubPrManager's refresh path, when iterating session.prs[], pass the entry's repo field to gh as --repo <repo>. The corresponding top-level path (prNumber / prRepository) already has prRepository populated and should be threaded the same way.

Pseudocode:

for (const pr of session.prs) {
  await runGh(["pr", "view", String(pr.prNumber), "--repo", pr.repo, "--json", "state,..."]);
  await runGh(["pr", "checks", String(pr.prNumber), "--repo", pr.repo, "--json", "..."]);
}

This removes the dependency on cwd being a git repo of the right remote, and matches how every prs[] entry is already shaped.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗