[Bug]: Pull Requests does not explain when a saved GitHub token cannot read a repository #24304

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 (GitHub Pull Requests listing)

Steps to reproduce

1. Configure a T3 environment with a saved github.com token that can authenticate but cannot access at least one private repository. For a fine-grained token, that repository may be outside its selected repository set.
2. Make sure the environment's fallback credential (GH_TOKEN or the gh login) can access that same repository.
3. From a T3 Code mobile client connected to that environment, refresh Pulls.
4. Observe a per-repository could not be read error.
5. Remove the saved token in Settings → Source Control and refresh. When the fallback credential can access the repository, the pull requests appear.

Expected behavior

When GitHub cannot return a repository to the active credential, T3 should explain that the repository may be inaccessible to that credential and show an actionable next step. The message should mention that a saved Settings token takes precedence over GH_TOKEN and the gh login, and point users to check the token's repository access or change the credential.

Actual behavior

The mobile Pulls view showed errors for multiple repositories, each reported only as could not be read. Source Control showed that the saved Settings token was active and overrode GH_TOKEN and the gh login. After removing the saved token, the user reports that the errors disappeared and supplied a screenshot showing pull requests in the list.

Impact

Major degradation or frequent failure: pull requests for affected repositories are unavailable until the credential is changed.

Version or commit

Unknown. The supplied screenshot identifies the client as T3 Code Beta but does not show its exact version or the server version.

Environment

T3 Code mobile client on iOS, connected to a macOS T3 environment. Exact OS, T3, and gh versions were not captured.

Logs or stack traces

No server logs were captured. Redacted UI evidence:

Before:
N errors loading pull requests
<redacted repository> could not be read.
Using the token saved in Settings; it overrides GH_TOKEN and the gh login.

After:
No token saved; the server uses GH_TOKEN or the gh login.
The mobile Pulls list populated.

Diagnosis

The observed change strongly suggests that the saved token could not access one or more affected repositories, while the credential used after its removal could. The old token is no longer available to inspect, so its repository selection and permissions cannot be confirmed.

Current main maps a GitHub response with a missing repository result to the generic The repository could not be read error, then formats the per-repository message as <repository> could not be read:

• GitHub source-control mapping
• Pull Requests list error

The status page identifies the saved token as the active credential, but that explanation is not present beside the repository error. A more actionable message could tell users to check repository access for the active credential without exposing private repository details.

Related issues

• #11247 covers GitHub App installation tokens failing the PR list because the /user endpoint is unavailable; the observed credential change here is different.
• #22966 covers fine-grained token access to check runs in PR details, not repository access in the list.
• #21365 covers multi-environment repository assignment. This report changed after removing a saved token; environment routing was not separately traced.

Workaround

Give the saved token access to the affected repositories, or replace/remove it if the environment's intended GH_TOKEN or gh login can access them. Removing the saved value from T3 does not revoke the GitHub token itself.

Screenshots

Not attached. The supplied captures contain private account, repository, and pull request identifiers; only redacted text is included.

Filed by

OpenAI Codex (GPT-6)