[Bug]: Pull request sync runs all projects' gh lookups from one directory, breaking per-account gh setups

[jcardama]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Use two GitHub accounts, each able to see a different set of private repositories. Account A sees org-a/*; account B sees org-b/*. Neither can see the other's repositories.
2. Select the account per repository with a small gh wrapper on PATH that sets GH_CONFIG_DIR from the working directory. Each account has its own config directory, so gh run from an org-a checkout authenticates as A, and from an org-b checkout as B.
3. Open projects for repositories from both orgs, with threads that have linked pull requests.

Expected behavior

Pull request lookups for a thread run in that thread's workspace, the way they did in 0.0.43-nightly.20260925.2269. Each lookup then authenticates as the account that can see the repository, and pull request status and the pull request pane load for every project.

Actual behavior

In 0.0.43-nightly.20260928.2375, pull request sync runs every project's lookups from one working directory. It appears to be the first project's workspace, unrelated to the thread. I sampled the spawned processes:

• gh pr view <n> --repo github.com/org-b/<repo> --json ... runs from the org-a project's directory, so it authenticates as A and fails with Could not resolve to a Repository.
• gh api graphql with a PullRequestSummaries query batches repositories from both orgs into one query (s0: repository(owner: "org-b", ...), s1: repository(owner: "org-a", ...)). No single account can answer that query. Under either account, GitHub returns partial data plus a NOT_FOUND error, and gh exits 1.

The server logs pull request sync skipped for every pull request in the other org each minute, and the pull request pane shows "Could not load pull requests. Pull request operation detail failed: GitHub CLI command failed."

Impact

Anyone who separates GitHub accounts per client or organization (for example with GH_CONFIG_DIR per directory, or with gh configured differently per checkout) loses pull request status and the pull request pane for every repository the directory T3 picked can't see. The only workarounds are giving one account access to every org, which defeats the separation, or routing the account from the command's arguments instead of the working directory.

Version or commit

Regressed between 0.0.43-nightly.20260925.2269 (works) and 0.0.43-nightly.20260928.2375 (fails). Possibly related to the pull request sync changes in #13704 or #13691, but I haven't bisected.

Environment

Linux x64, server run as a systemd user service, gh 2.x.

Logs or stack traces

[17:43:25.899] WARN (#513610): pull request sync skipped
  { key: 'github.com/org-b/repo-x#15' }

A mixed-owner query reproduces the partial failure directly under either account:

$ gh api graphql -f query='query { s0: repository(owner: "org-b", name: "repo-x") { pullRequest(number: 15) { state } } s1: repository(owner: "org-a", name: "repo-y") { pullRequest(number: 41) { state } } }'
{"data":{"s0":null,"s1":{"pullRequest":{"state":"OPEN"}}},"errors":[{"type":"NOT_FOUND","path":["s0"],...}]}
gh: Could not resolve to a Repository with the name 'org-b/repo-x'.
exit status 1

Workaround

Route the account from the repository named in the command (--repo, repos/<owner>/..., GraphQL owner:) rather than the working directory. That restores the per-pull-request lookups. A mixed-owner batched query still fails for one side.

Suggested fix: run lookups from each thread's workspace as before, or batch GraphQL queries per workspace or per credential rather than across all projects.

[juliusmarminge]

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:

  const summaryResolver = RequestResolver.makeGrouped<PullRequestSummaryRead, string>({
    key: ({ request, context }) =>
      JSON.stringify([
        request.host.toLowerCase(),
        Context.getOrElse(context, GitHubCli.PinnedGitHubCredential, () => null)
          ?.credentialFingerprint ?? null,
        Context.getOrElse(context, SourceControlRateLimit.CredentialScope, () => ""),
      ]),
    resolver: (entries) => {
      const [first] = entries;
      // ...
          : graphqlRead({
              cwd: first.request.cwd,
              host: first.request.host,
              operation: "getPullRequestSummary",
              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.