GitHub repository connection

Before connecting GitHub

Use this page when a fix task or remediation plan needs repository context for the code that owns the affected issue. The connection should use the product GitHub App flow and the smallest repository scope that can support indexing or review-only patches. Do not paste tokens, private keys, repository secrets or source snippets into documentation, tickets or chat. If the correct repository or approval is unclear, use fallback or revoke paths before indexing starts.

Connect the repository

Follow the path `Fix task → Connected access request → GitHub App install → Repository selection → Read-only indexing or fallback`.

1. Open /projects/{project}/repository-provider/github/connect from the project that owns the affected report or fix task. Result: repository_connection_status and provider_key are shown for the correct project before access is requested.
2. Choose the GitHub organization or owner that contains the affected repository. Result: installation_id is tied to the customer-owned GitHub App installation, not a personal token.
3. Select only the repository that contains the affected code. Result: repository_full_name matches the project domain, report evidence and fix task context.
4. Confirm read-only or review-only scope before continuing. Result: WebRiskOps can index code or prepare review-only patches without broad repository access.
5. Check the connected state after GitHub returns. Result: provider, installation, repository and scope are visible before read-only indexing starts.
6. Use fallback or revoke paths if the owner, repository, scope or approval is wrong. Result: unsupported or unsafe access does not lead to indexing, patch generation or PR creation.

Ready connection states

Continue only when the product shows a ready or reviewable state.

• Connected means repository_connection_status, provider_key, installation_id and repository_full_name are present for the correct project.
• Read-only ready means the repository can be indexed without creating branches, commits or pull requests.
• Review-only ready means generated patch suggestions can be prepared for customer review before any PR action.
• Approval required means the repository is selected but a repository admin or project owner must approve the access mode.
• Fallback available means ticket-only or customer-applied evidence can continue when connected access is unsafe.

Blocked or unsafe states

Do not work around unsafe access.

• Wrong repository means disconnect or revoke access and choose the repository that actually owns the affected code.
• Broad access request means stop before indexing and return to access-mode guidance.
• Missing approval means do not create PRs or review-only patches until the customer approval state is clear.
• Provider error means retry the connection only through the product flow or use a safe fallback path.
• Enterprise host mismatch means use GitHub Enterprise considerations before trying the cloud GitHub App flow again.
• Secret exposure risk means use revoke and no-secret boundaries before reconnecting.

Continue to indexing

When the repository is connected with the correct scope, continue to Read-only indexing. Use GitHub Enterprise considerations when the customer uses a self-hosted or enterprise GitHub environment. Use Safe fallback paths when the repository, approval or provider state cannot be made safe enough for connected remediation.