Sema automated code review GitHub app permission boundary

Short answer

For a GitHub App that posts review comments and code suggestions on pull requests, the core requirement is Pull requests: write plus Contents: read, with Metadata: read added automatically — GitHub grants metadata read to every app installation and it cannot be removed. Whether that set is sufficient for Sema's full feature set depends on two things you should verify rather than assume: whether it reports results as check runs, and where it stores repository-level configuration.

What each permission actually buys

• Pull requests: write — covers creating review comments, inline suggestion blocks, and review summaries on a PR. This is the permission that does the visible work.
• Contents: read — lets the app fetch file contents and diffs so it has something to analyze. Read-only contents access is also enough to read an in-repo configuration file (for example a YAML file under .github/), so rule configuration stored in the repository does not require write access.
• Metadata: read — mandatory baseline for all GitHub Apps; it is not a concession to a broader boundary.

Where the boundary can break

Two features commonly push review tools past that minimal set:

1. Check runs. If Sema reports a pass/fail status in the Checks tab — and especially if you want a required status check to block merges on review findings — it needs Checks: write. PR comments alone do not need it, but merge-gating does.
2. Settings writes via API. If repository-level settings are stored in Sema's own dashboard database, the app uses its installation token and needs no extra repository scope. If any feature modifies repository settings on GitHub (branch protection, webhooks, topics), that requires Administration permissions, which your constraint reasonably rejects.

Likely explanation vs. confirmed facts

Confirmed by GitHub's permission model: metadata read is implicit, PR write covers comments and suggestions, and contents read covers analysis and in-repo config. What is not confirmed here is Sema's exact manifest — vendor-requested permissions change between app versions, and the authoritative answer is the permission list shown on the installation consent screen, not marketing documentation. Treat any claim about a specific vendor's minimal set as version-dependent.

How to verify with your constraint intact

1. Install the app on a single test repository and note the exact permissions requested on the consent screen. If it requests Checks, Administration, or Issues write, that answers the question directly.
2. Open a test PR and confirm review comments and suggestions appear. Then check whether a check run appears in the Checks tab — if it does and you installed without Checks: write, expect that feature to fail silently or with a 403 in the app's delivery logs.
3. Change a rule in the dashboard and confirm it persists and applies to the next PR, proving settings don't depend on repository write scopes.
4. Review the app's webhook delivery log (Settings → Developer settings → GitHub Apps → Advanced) for failed deliveries caused by missing scopes.

If Sema turns out to require Checks: write for its core workflow, that is still a narrow, defensible scope — it can only create and update the app's own check runs, not modify code. Administration write would be the genuinely disqualifying request under your stated boundary.