Doctorine GitHub App permissions
Last reviewed: 2 September 2026
Doctorine uses one GitHub App for documentation sync and generated SDK repositories. You choose the repositories it can access. Doctorine then uses short-lived, single-repository tokens for each SDK operation instead of a broad installation token.
Permissions used for SDK publishing
| Permission | Access | Why | Boundary |
|---|---|---|---|
| Metadata | read | Identify the selected repository and its default branch. | Repository metadata only; no repository content is read through this permission. |
| Contents | write | Write generated SDK code and managed release branches. | Used only in repositories selected for Doctorine and with a single-repository token. |
| Pull requests | write | Open and update generated SDK release pull requests. | Does not bypass branch protection or required checks. |
| Checks | write | Publish Doctorine generation and release checks. | Check results describe Doctorine work; they do not change repository settings. |
| Workflows | write | Install and update the managed publishing workflows committed with an SDK. | Doctorine does not write workflow secrets. |
| Actions | write | Inspect managed runs and disable a Doctorine workflow after a security revocation. | Reserved for Doctorine-managed workflows and their recovery path. |
| Repository variables | write | Maintain the non-secret DOCTORINE_PUBLISHING safety gate. | Variables are not secrets; Doctorine never requests repository-secret write access. |
| Merge queues | read | Evaluate the exact queued commit before a safe automatic merge. | Read-only; Doctorine cannot change merge-queue rules. |
Permissions reserved in the same approval wave
GitHub requires every installed account to approve new permissions. These narrowly bounded capabilities are requested together so customers do not face another consent ceremony as the release workflow grows.
| Permission | Access | Purpose | Boundary |
|---|---|---|---|
| Commit statuses | write | Reserved for release-status integrations that use the same verified commit. | Future-baked into the one approval wave; not a repository-settings permission. |
| Deployments | write | Reserved for publishing durable release and deployment records. | Future-baked into the one approval wave and limited to Doctorine releases. |
| Environments | write | Reserved for SDK publishing environment records. | Does not grant access to environment secrets. |
| Issues | write | Reserved for actionable release and compatibility reports. | Future-baked into the one approval wave; Doctorine does not alter unrelated issues. |
| Administration | read | Read branch-protection and ruleset requirements before automatic merging. | Read-only. Doctorine cannot change repository settings, rules, or protection. |
| Organization members | read | Reserved for organization-aware approval and ownership checks. | Read-only and never used as Doctorine authentication. |
Why does Doctorine request Administration read access?
Doctorine reads branch-protection and repository rules before attempting an automatic merge. The permission is read-only: it cannot change settings, protection, rulesets, collaborators, or repository visibility.
Which permissions does Doctorine refuse?
- Repository and organization secrets write access
- Repository and organization administration write access
- Organization webhooks and repository-webhook management
- All user and account permissions
In particular, Doctorine does not request access to write repository or organization secrets. Customer-owned fallback credentials remain under the customer's control.
What happens while an update awaits approval?
- GitHub keeps the previously approved permissions active until an account administrator accepts an update.
- Documentation sync continues while approval is pending, but new SDK repository links stay blocked.
- Doctorine records the accepted set per installation and releases the SDK gate only after the required subset is observed.
How is repository access limited?
The account administrator chooses which repositories the App can access. SDK provider operations mint a short-lived token restricted to exactly one selected repository and the minimum permissions for that operation.
Which GitHub events does the App receive?
The App subscribes to repository, push, pull-request, check-suite, and merge-group events. They drive repository lifecycle, regeneration, release pull requests, verified checks, and exact merge-queue evaluation. Event delivery never grants access beyond the installation's accepted permissions and selected repositories.
What happens if the App is uninstalled?
Generated SDK code and release history already written to the customer's repository remain there after the App is uninstalled. Uninstalling or removing a repository stops Doctorine from generating, updating, or publishing through that installation.