Triage
Confirmed on current main (d15210cd, which is v0.0.43-nightly.20260928.2375). The mixed-owner PullRequestSummaries query is what this sync does. Not a duplicate of #14113: that failure is an interrupt on first open (All fibers interrupted without error). This one is gh exiting 1.
Background sync asks for every due link together (PullRequestSyncReactor, concurrency 25). Each summary becomes a PullRequestSummaryRead, and those reads are grouped only by host and pinned credential:
| 1 | const summaryResolver = RequestResolver.makeGrouped<PullRequestSummaryRead, string>({ |
| 2 | key: ({ request, context }) => |
| 3 | JSON.stringify([ |
| 4 | request.host.toLowerCase(), |
| 5 | Context.getOrElse(context, GitHubCli.PinnedGitHubCredential, () => null) |
| 6 | ?.credentialFingerprint ?? null, |
| 7 | Context.getOrElse(context, SourceControlRateLimit.CredentialScope, () => ""), |
| 8 | ]), |
| 9 | resolver: (entries) => { |
| 10 | const [first] = entries; |
| 11 | // ... |
| 12 | : graphqlRead({ |
| 13 | cwd: first.request.cwd, |
| 14 | host: first.request.host, |
| 15 | operation: "getPullRequestSummary", |
| 16 | query, |
Sync never pins a credential, so every github.com link that arrives in the 10ms window shares one group. The query runs in entries[0]'s working directory, which is whichever request got there first, not the thread that owns the repository. gh exits 1 when any aliased repository is invisible to that directory's account, the whole document is dropped, and the sweep logs pull request sync skipped with only the key.
A failed document is then supposed to fall back to one gh pr view per entry, using that entry's own cwd. summary sets that cwd from the project requireProject returns. When the link's repository matches the thread's project, that is the thread's checkout. repositoryArgs always passes --repo <host>/<owner>/<name>, so --repo github.com/org-b/... does not by itself mean the target was rewritten.
A gh pr view for org-b whose process cwd is an org-a checkout means the serving project was not org-b. That is the host fallback in requireProject: a GitHub ref may be answered by any checkout on the host, and the last resort is the first non-Azure checkout, with the requested repository written onto it. The pull-request list (readTogether) and listStats do the same thing on purpose (cwd is chunk[0]'s workspace; the search API comment says "any checkout on the host"). Detail is not in the summary batch. Pull request operation detail failed: GitHub CLI command failed is that read's own gh failing in whichever checkout requireProject selected, which is also what the pane renders.
This resolver is unchanged between v0.0.43-nightly.20260925.2269 and 2375. It landed in #13198 (2026-09-22), which is already in 2269. #13704 only stops the sweep from loading threads that have no links. #13691 changes which threads settlement reads, not which directory gh runs in. If 2269 really did run each lookup in the thread checkout, the difference is whether those reads landed in one 10ms batch. The code that collapses them was already there.
Group summary batches by the credential gh auth token returns in that request's cwd (the fingerprint captureVerifiedCredential already computes), and run each query from a cwd that produced it. Do the same for the list and stat reads that take the first workspace in the chunk. A mixed-owner document cannot be split after gh has already failed it.
