What you need
- The owner and repository name (for example acme / api)
- The base branch fixes should branch from — main unless you say otherwise
- A fine-grained personal access token scoped to that one repository, with Contents: read and write, and Pull requests: read and write
Why write access at all
Reading code needs only read access. The write half exists for exactly one action: pushing a branch and opening a draft pull request when the proposed fix is a code change. Nothing else in this product writes to your repository — no pushes to existing branches, no merges, no releases, no comments.
A draft pull request is the safest possible write. GitHub will not merge one, auto-merge ignores it, most CI configurations skip it, and closing it takes a click. That is why stage 4 is allowed to do it without waiting for an approval, while a command list is not.
What the draft PR actually contains
The model produces a precise description of the change, not a compiled and tested patch — so the branch carries a proposal document under .incident-copilot/ describing what to change and why, together with the root cause and the confidence rating. An engineer implements the change on that branch, deletes the proposal file, and marks the PR ready for review.
This is deliberate. Committing machine-written code that was never compiled or tested, onto a branch named after a live production incident, would be worse than committing a clearly labelled proposal.
Set it up
- Connectors → Add connector → GitHub
- Enter the owner, repository, and base branch, and paste the token
- Click Test connection — it shows the repository's full name and the permissions your token actually has