Sema GitHub integration: individual OAuth vs organization GitHub App for least-privilege access and credential renewal

Short answer: Sema's public documentation does not clearly state which GitHub authentication model it uses by default, so the only safe answer is to verify directly before committing. That said, the two models behave in well-documented ways on GitHub's side, and you can determine which one Sema uses — and whether it meets your least-privilege requirements — with a few concrete checks described below.

What is confirmed vs. what is likely

Confirmed (GitHub platform behavior):

• A user OAuth grant acts on behalf of one user and inherits everything that user can see. You cannot scope it below the user's existing repository access. When the token expires or is revoked, that specific user must re-authenticate; API calls return 401/403 in the meantime.
• A GitHub App installation can be scoped to selected repositories at install time. It uses short-lived installation tokens (about one hour) that the app refreshes itself, so there is no user-driven re-login on expiry. Revocation is immediate and controlled by an organization admin from GitHub's settings, independent of any individual's account.
• When credentials fail, GitHub returns 401/403 on the next API call. Whether the integration surfaces this as an explicit sync error or silently stops updating pull requests is an implementation choice of the vendor.

Likely but unverified (Sema-specific): Most code-review SaaS platforms targeting organizations prefer the GitHub App model precisely because it supports repo-scoped installation and admin-controlled revocation. However, Sema's default model, whether both models are supported simultaneously, and how it surfaces token failure are not stated in publicly available documentation. Treat any assumption here as provisional.

How to determine which model Sema uses

1. Start the connection flow (trial if available). A GitHub App flow shows an Install screen with an "All repositories" vs. "Only select repositories" choice. An OAuth flow shows an Authorize screen listing OAuth scopes instead.
2. After connecting, check GitHub org settings → Third-party Access → Installed GitHub Apps. A Sema entry there confirms the App model; an entry under Authorized OAuth Apps in a user's settings confirms the OAuth model.
3. Ask Sema support directly: "Do you support GitHub App installation with per-repository scoping, and what appears in the UI when the installation is suspended or uninstalled?"

Recommendations by model

If Sema supports a GitHub App installation: use it. Install scoped to only the repositories under review, and revocation and lifecycle management sit with your org admins rather than any individual. Token refresh is automatic; the main failure mode to test is what Sema displays when the installation is suspended or uninstalled — expect a sync or authorization error, but confirm it is not a silent stop.

If Sema only supports user OAuth: least-privilege scoping is not achievable through the integration itself. The practical workaround is a dedicated GitHub service account whose repository access is limited to exactly what Sema should see, then authorize Sema as that account. Document that re-authentication depends on that account, and add an expiration/revocation check to your runbook.

One detail that changes the recommendation

Does your organization allow third-party GitHub App installations at all? Some orgs restrict them by policy, which would force the OAuth path regardless of Sema's capabilities. Confirm this with your GitHub org admin before evaluating further.