[Bug]: Pull Requests "Authored" resolves one viewer per host, so a second account on github.com never matches#16068
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
- Use two GitHub accounts on
github.com. Account A can seeorg-a/*, account B can seeorg-b/*, and neither can see the other's private repos. - Route
ghper directory: a small wrapper setsGH_CONFIG_DIRfrom the working directory, soghrun in anorg-acheckout is A and in anorg-bcheckout is B. Runninggh api userin each checkout confirms that. - Add projects from both orgs to T3 Code.
- Open the Pull Requests page and switch to Authored.
Expected behavior
Authored shows PRs authored by A in org-a repos and PRs authored by B in org-b repos, since each project is read with the account its own checkout resolves to.
Actual behavior
Authored only ever shows PRs from one of the two accounts (in practice whichever project root sorts first). Every PR authored by the other account is missing. All still lists them, so the repos can be read, they just never match the author filter.
Narrowing the page to a single org-b project doesn't help either: Authored still filters by account A for up to 10 minutes.
Cause
The viewer (the login that author: / --author / review-requested: compare against) is resolved once per host, not per credential:
viewersByHostis keyed by host only, andgetViewertakes the first project root that answers viaEffect.firstSuccessOf(roots...): https://github.com/pingdotgg/t3code/blob/1a3f7ad5085606463a602bd756ca9c04d106fffe/apps/server/src/pullRequest/PullRequestService.ts#L978-L1002resolveViewershands back that cached per-host result forVIEWER_CACHE_TTL(10 min) whatever the project filter is: https://github.com/pingdotgg/t3code/blob/1a3f7ad5085606463a602bd756ca9c04d106fffe/apps/server/src/pullRequest/PullRequestService.ts#L1023-L1041PullRequestListResult.viewersis ahost -> loginrecord, so the contract can't express two accounts on one host either.
A related side effect: readTogether runs the cross-repo search from the first project's cwd, so a batch with repos from both orgs gets searched with one account's credential. Repos the other account owns come back empty and fall back to per-repo reads, which costs extra requests: https://github.com/pingdotgg/t3code/blob/1a3f7ad5085606463a602bd756ca9c04d106fffe/apps/server/src/pullRequest/PullRequestService.ts#L1340-L1352
This is the same class of problem as #14123 (one directory/credential used for projects that belong to different accounts), but in the list's viewer resolution rather than the sync reactor.
Suggested fix
Resolve the viewer per credential (GitHubPullRequestCli already computes a credentialFingerprint and viewer per cwd in captureVerifiedCredential), group projects by that credential, not just by host, and run each group's search with its own viewer. For the contract, viewers could be keyed by credential/account, or each entry could carry the viewer it was matched against.
Impact
Major degradation or frequent failure
Version or commit
T3 Code Nightly 0.0.46-nightly.20261005.2676 (code refs above are main @ 1a3f7ad508)
Environment
macOS 26, desktop app, gh 2.102.0, two github.com accounts routed per directory via GH_CONFIG_DIR
Workaround
None inside T3 Code. Use All and scan for your own PRs, or use gh pr list --author @me in each checkout.
Synced from GitHub
This is a regression for me too, and it breaks auto-settle as well as the Authored filter.
Setup: two accounts on github.com, both logged in to the same gh config. Account A sees org A, account B sees org B, and neither can see the other org's private repos. A gh wrapper on PATH picked the account from the repo's owner (--repo, gh api repos/<owner>/…, or the git remote). Up to the nightlies before #16319–#16322, PR sync worked for both orgs and threads auto-settled when their PR merged.
Since 0.0.46-nightly.20261010: GitHubCredentials runs gh auth token --hostname github.com from the server's directory. That gives the wrapper no repo to go on, so every project gets the active account. PR reads for the other org fail with GitHubApiNotFoundError: … or the credential cannot see it, linked PRs never show as merged, and those threads never auto-settle. Pinning an account in Settings → Source Control only moves the breakage to the other org.
Proposal: build on the new per-host account choice and let me pick an account per organization (repo owner), for example org-a → account-a and org-b → account-b. Repos with no rule would fall back to the per-host account. T3 would pass the chosen account as gh auth token --user, so no wrapper is needed, and one setting covers every repo in an org, including ones added later. If per-org is too much, an account per project would also work for me. Either way, reads would need to be batched per credential so one org's PRs aren't fetched with the other org's token.
Synced from GitHub
Related reproduction and implementation: #21264 and #21265. Separate organisation-scoped PATs can belong to the same GitHub login, so the viewer name alone cannot identify the credential that can read a repository.
With the proposed Git-helper option enabled, the server resolves the viewer using each repository's selected credential for Authored filtering and isolates token-dependent caches and batches by fingerprint. Host-wide default identity remains unchanged. This addresses the repository/credential part of this issue for Git HTTPS helper setups; it does not claim to resolve every multi-environment account-routing or UI case. The PR includes same-login/different-PAT, rotation and mixed-organisation regressions plus native remote checks.
Classified as a bug; the report does not describe an exploitable vulnerability. Checked open issues in 19 pages (947 issues) for Authored, viewer, multi-account/second-account, and the credential visibility error; no duplicate with the same symptom was identified. Prepared current main at b5a226e49c in an isolated worktree. Reproduction stopped at the account prerequisite: this VM has no configured GitHub account entries or GH_TOKEN/GITHUB_TOKEN, so the two-account, disjoint-private-repository setup cannot be exercised. No runtime reproduction is claimed. Leaving open for maintainer triage; no fix or PR was created.