GitHub connector

The connector reads pull request events for the repositories you choose and labels the coding-agent runs that produced them. A merge is a provisional success. A proven revert inside the window turns it into a failure. For what the labels mean and which one wins, see Outcomes that fill themselves.

Only an organization owner or admin can connect, change repositories or disconnect. Other members can see the connection’s health.

Set it up

Open Settings > Outcomes (/settings/outcomes) and choose the environment to connect. The connection belongs to that environment only: a staging connection never labels production runs.
Select Connect GitHub. Morse opens GitHub’s install page for the Morse app. The link carries a single-use code that expires after 15 minutes and is tied to you, your organization and the environment.
Choose the repositories to share with the app, then finish. GitHub sends you back to Settings > Outcomes, where Morse checks that the GitHub account you signed in with can access that installation before it stores anything.
Under Repositories to read, tick the repositories Morse should use and save. Giving the app access on GitHub is not enough; a repository is read only after you select it here.
Check the match preview. It shows how many runs in the environment carry a key for that repository, how many pull requests those keys name, and how many already have a merge on record, before anything is labeled.

If Connect GitHub says GitHub is not available on this deployment, the Morse GitHub App is not configured there. You can still send outcomes from your own code with the record outcomes API.

What the app can see

The app needs two read-only permissions: Metadata and Pull requests. It does not request repository contents, so it cannot read your source files. Morse stores pull request state (number, merge time, base branch, file and line counts, and which pull request a revert names). It does not store titles, descriptions or diffs, and a pull request’s changed files are read only to prove a revert.

Disconnecting, suspending or uninstalling the app, or removing a repository from it, stops new outcomes for that repository. Labels already written stay in the history.

Run the app yourself (self-hosted setups)

If you operate your own Morse deployment, the app’s Setup URL is <app origin>/settings/outcomes, its webhook URL is <API origin>/api/v1/connectors/github/webhook, and it needs the pull request, installation and repository events. Enable “Request user authorization (OAuth) during installation” so the install can be verified. The environment variables are listed in the engineering runbook (engineering/ENVIRONMENTS.md, “GitHub connector”).

What a merged pull request means

When a pull request merges, every eligible run keyed to it gets a success from the webhook source, dated at the merge time and provisional until the merge time plus the window.

The window is 7 days by default and can be changed per agent, from 1 to 365 days, on Settings > Outcomes (Maturity window per agent).
Edits apply to future pull requests only. Each pull request keeps the window that was in force when Morse first labeled runs for it, so changing the window never moves a pull request already in flight.
A pull request closed without merging produces no label. It is not a failure.
A run is eligible only if it started before the merge (plus 5 minutes of clock skew) and carries the key in the connected environment.

How a revert is proven

A failure is written only for a revert Morse can prove, never from a link or a title alone. All of these must hold:

A merged pull request in the same repository names the original: a line starting Reverts #123 or Reverts owner/repo#123, or This reverts commit <sha>. This only selects a candidate. It is not proof.
It targets the same base branch and merged after the original.
It merged within the window of the original’s merge (7 days by default).
Its changes are the complete inverse of the original’s: the same files, with additions and deletions swapped, across every changed file, and both file listings are complete.

When Morse cannot prove it, the revert stays unresolved and no failure is written. That covers manual reverts, cherry-picks, partial reverts, renamed or binary files, very large pull requests and anything GitHub does not return in full. An admin can confirm it from Reverts needing a decision. The confirmation is recorded with the admin’s identity and still has to satisfy the order and base-branch checks.

A verified revert appends a failure at the revert’s merge time and links it to the success it corrects. The original event stays in the history. If a later merged pull request is proven to revert the revert, the failure is superseded by a new provisional success from that merge time, with a fresh maturity date. A revert merged outside the window is shown with that reason and changes nothing.

Match runs to pull requests

⚠️

Requires SDK 0.7.0 (not yet released; 0.6.0 does not have this). link_record() is a 0.7.0 SDK call. On 0.6.0, send the github_pr record key over REST or OTLP instead (see Record keys and versions).

Runs are matched only through a record key. Set github_pr on the run with the repository included:


morse_ai.link_record("github_pr", "acme/checkout-service#4211")

Rule	Detail
Key type	`github_pr`
Key value	`owner/repo#number`, matched lower-cased. A repository’s earlier names after a rename still match.
A bare number	`1123` is ambiguous across repositories and never matches. The match preview counts these runs and says they cannot match.
A deployment revision	A git revision alone never matches. Many runs share one deployment SHA, and a SHA is not a pull request.
Environment	Only runs from the environment the installation is connected to.
A key that arrives late	A run that gains its key after the pull request was processed is labeled from the retained pull request state. If that state is no longer retained, the run is shown as unmatched.

⚠️

The GitHub Actions example in the record outcomes API sends a bare pull request number. For the connector, use owner/repo#number as the key value on the run, and in any event you send for the same pull request.

Check that it is working

Settings > Outcomes shows connection health: pending and failed deliveries (failed ones are retried automatically), runs blocked by a higher-confidence label, and runs blocked by another source. A run that already has a developer label keeps it; the connector does not replace it.

Limitations

Merged is not code quality. A pull request that merges and is never reverted is a weak signal that the change was kept.
GitHub is the only connector. There is no GitLab, Bitbucket or ticketing connection.
Morse does not predict when a label will arrive.
A revert that cannot be proven needs an admin’s confirmation before it counts.