Repository navigation
fix(github): support installation tokens across source control workflows - #21184
rickbassham wants to merge 14 commits into
Conversation
ApprovabilityVerdict: Needs Human Approval Macroscope's review found this PR requires human approval — This PR substantially broadens GitHub authentication support across discovery, PR operations, cloning, publishing, and repository creation, including new GraphQL mutations and credential-handling paths. The sensitive, cross-cutting runtime and product-default changes warrant human review. You can add or adjust custom eligibility rules. Learn more. |
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Viewer identity and bot-aware actors packages/source-control-github/src/server/gitHubViewer.ts, packages/source-control-github/src/server/GitHubPullRequestApi.ts, packages/source-control-github/src/server/gitHubPullRequestJson.ts, packages/source-control-github/src/server/pullRequestListings.graphql*, packages/source-control-github/src/server/GitHubPullRequestProvider.ts, packages/source-control-github/src/server/GitHubPullRequestApi.test.ts, packages/source-control-github/src/server/GitHubPullRequestProvider.test.ts |
A shared viewer reader falls back to GraphQL after a REST 403. Bot logins are normalized across actor, reviewer, and avatar mapping. Review-thread results no longer include a separate bot-login set. |
Credential refresh and host discovery packages/source-control-github/src/server/GitHubCredentials.ts, packages/source-control-github/src/server/GitHubSourceControlProvider.ts, packages/source-control-github/src/server/GitHubSourceControlProvider.test.ts, packages/source-control-github/src/server/gitHubDiscovery.test.ts |
Environment-token variable selection is exposed separately from token reading. Provider discovery checks eligible hosts and prioritizes authentication according to the configured default host and discovery results. |
Installation repository lookup and publishing packages/source-control-github/schema/github.graphql.ts, packages/source-control-github/graphql.config.ts, packages/source-control-github/src/server/sourceControlProvider.graphql*, packages/source-control-github/src/server/GitHubSourceControlProvider.ts, packages/source-control-github/src/server/GitHubSourceControlProvider.test.ts, packages/source-control-github/src/shared/definition.ts, apps/web/src/components/GitActionsControl.tsx, packages/client-runtime/src/operations/projects.test.ts, docs/user/source-control.md |
GraphQL operations look up installation owners and create repositories. Bot accounts use installation-owner resolution, and publish-target selection excludes bot accounts as owners. The publish dialog uses the selected provider’s owner result. Documentation describes App-token use and limitations. |
Pinned GitHub operations and API coverage packages/source-control-github/src/server/GitHubSourceControlProvider.ts, packages/source-control-github/src/server/GitHubSourceControlProvider.test.ts, packages/source-control-github/src/server/GitHubPullRequestApi.test.ts |
Pull request creation pins credentials and sets fork maintainer-edit permissions based on the viewer. Clone URL lookup selects credentials for the explicit repository host. Tests cover listing fallback, quota handling, and reviewer request endpoints. |
Priority:
Estimated code review effort: 4 (Complex) | ~60 minutes
Change: Bug fix
Sequence Diagram(s)
sequenceDiagram
participant GitHubSourceControlProvider
participant GitHubCredentials
participant GitHubREST
participant GitHubGraphQL
GitHubSourceControlProvider->>GitHubCredentials: Get credential for selected host
GitHubSourceControlProvider->>GitHubREST: List installation repositories
GitHubSourceControlProvider->>GitHubGraphQL: Resolve owner by login
GitHubGraphQL-->>GitHubSourceControlProvider: Return owner ID
GitHubSourceControlProvider->>GitHubGraphQL: Create repository with owner ID and visibility
GitHubGraphQL-->>GitHubSourceControlProvider: Return repository URLs
Possibly related issues
- pingdotgg/t3code#14939: The changes select credentials using the explicit repository host during clone URL lookup, matching the issue’s reported host-selection objective.
Suggested reviewers: juliusmarminge
Merge Risk: 
Minimal · up to 08db7
-
This change adds GitHub App installation-token support for identity checks, Bot and human actor separation, clone and repository creation, and fork pull requests. No concrete merge-blocking defect was found in the supplied evidence. Maintainers should still smoke-test with real installation credentials, as the author suggests.
Security architecture risk: 
Low · up to c7fae
-
Installation tokens gain working access to existing GitHub workflows, but credentials remain bound to a host and repository creation verifies the destination owner. No material security regression was established. Token expiration and interrupted creation still require operational care.
Retained concerns
No architecture-level concerns identified.Security review details
-
Security Blast Radius
- inferred — The effective authority is the configured credential's GitHub access, potentially covering all repositories available to an installation and repository creation where granted. This PR makes that authority usable through existing workflows; it does not mint broader credentials. Git clone, fetch, and push retain a separate authentication dependency.
Trust Boundaries and Controls
- observed — Repository selectors can choose a destination host and owner, but credential lookup is host-keyed and a pinned credential rejects a different host. Saved tokens retain precedence over environment and CLI credentials; enterprise environment tokens remain restricted to GH_HOST. Owner lookup data must match the requested login before creation.
Resilience and Maintainability Implications
- observed — Credential-pinning regression coverage changes the credential source during creation and verifies that identity, owner lookup, and mutation continue using the captured credential. A separate test verifies that missing creation details do not trigger another mutation. These checks support identity consistency, but do not establish recovery after cancellation or an external commit followed by connection loss.
-
Pre-merge checks: 
4
-
Full details: Description check
-
Explanation
The description is detailed and covers the problem, implementation scope, verification results, limitations, and required maintainer checks. It is substantially complete and directly aligned with the pull request objectives.
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
|
Taking over this one as maintainer for batch pull-request-14. I’ll keep this as a focused fix on the original PR, reduce the tests to the essential installation-token workflows, rebuild against current main, and verify identity fallback and bot/human separation before publishing. Thanks @rickbassham for tracing the App identity, fork-PR and repository-creation behavior. |
|
Note Written by updated the original branch at i reused main's existing viewer query, moved the bot publish-owner rule to the shared provider definition, preserved main's commit statistics and tracing, and removed obsolete duplicate tests. no new test files. verification:
unverified: real installation-token operations, expiry/replacement, new-repository permission/partial-creation recovery, and native clients. @rickbassham, real app-token confirmation would help close those external verification gaps. human approval is still required for the authentication scope. |
|
Tested the updated PR head with a real GitHub App installation token on 2026-10-26. Version/environment: Authentication: the Passed through the running T3 application, using its normal HTTP/WebSocket APIs:
Headless Chromium web UI passed: paired with the same candidate, revealed the GitHub account as Publish limitation: attempted Still unverified: successful repository creation with a suitably permitted installation, failure after successful remote creation / partial-creation recovery, natural token expiry, same-slug human/bot reviewer edge cases with real accounts, and native desktop/mobile clients. These results do not replace maintainer approval for the authentication scope. |
|
This PR conflicts with See the conflict window. |
|
Note 🤖 Claude Opus 5.5 responding on behalf of Theo Closing. This PR conflicts with |


GitHub App installation tokens fail REST identity verification, and GraphQL Bot slugs can be confused with humans sharing that slug. This completes @rickbassham's original #21184, preserving the contributor commits and merging current main without rewriting the fork branch.
The rebuilt identity reader falls back from REST
/user403 to a typed GraphQL viewer using the captured credential. Actual Bot actors get canonical names at the decoder boundary; same-slug humans keep their identity across listings, activity, reactions and reviewer requests. Clone, create and fork-PR workflows pin credentials, honor explicit destination hosts, infer an App installation owner from paginated repository metadata, and require an explicit owner when inference is inconclusive. App repository creation verifies the owner and sends one mutation, reporting refusal or possible partial success without retrying. App fork PRs disable maintainer modification.App identities have no automatic new-project publish target. Manual publishing leaves the Bot owner empty. The dialog now uses each provider's existing owner rule, so Bitbucket/Azure prefills also become blank. Existing human Enterprise and self-hosted GitLab publishing targets are preserved. Discovery retains Enterprise-only authentication and prefers a valid public CLI identity over an unrelated saved Enterprise token.
Verification at 3d5dcadb8c:
No visual or native-client verification is claimed. T3 browser attempts failed with
Preview automation snapshot timed out after 15000ms.andPreview automation navigate timed out after 15000ms.; the authorized API/test fallback was used. macOS, Windows, iOS, Android and Electron shell behavior were not exercised.Before approval, a maintainer should use real installation credentials for listing/detail, reviewer changes, fork PRs, clone and permitted personal/organization creation; check repository-limited token partial-creation recovery and expiry/replacement. Token issuance/renewal and Git HTTPS/SSH authentication remain external. A saved token's identity can still be labeled as a gh login in web Settings. A saved human Enterprise token without
GH_HOSTcan expose the existing failing automatic public-host publish option; use an explicit Enterprise destination. This PR makes no new generic publishing-host guarantee.Current-head CI is green: lint, build/typecheck, all eight server shards, general tests, web tests and native fingerprint pass. The first run hit an Electron download DNS error and two browser timing failures; both browser suites passed locally (6/6 actual Chromium tests), and one failed-job retry passed. Normal preview/native/release jobs skipped. CodeRabbit status is successful with no review threads; its narrative still describes the contributor head. Four independent whole-PR review rounds cover the current implementation. Authentication scope requires human review and live App verification remains; this is unmerged.
Models/harness: fresh Codex GPT-6-Astra tests, Codex GPT-6.1-Sol implementation, independent Claude Opus 5.5 and Codex GPT-6-Sol reviews through T3 Code; primary integration through the Codex harness.