Overview

Installations are the GitHub App coverage layer behind Mogplex repo automation.

There is not a separate top-level /installations dashboard route today. This docs section describes the GitHub App installation state surfaced in Settings and consumed by Projects, Triggers, and Automations.

The distinction to keep explicit

For most setup problems, there are three states a repo can be in:

1. not visible at all
2. visible through GitHub OAuth
3. covered by a Mogplex GitHub App installation

Only the third state is fully eligible for App-backed routing and automation.

That is why Installations deserves its own docs section even though the product does not currently expose it as a standalone top-level dashboard page.

Why installations matter

An installation answers two different questions:

1. which account or org has granted the Mogplex GitHub App access
2. which repos are therefore eligible for App-backed behavior

That second point is the important one. A repo can be visible through OAuth and still not be triggerable.

OAuth vs installation coverage

Keep this distinction explicit:

• GitHub OAuth gives Mogplex an authenticated user identity and supports repo discovery
• GitHub App installation gives Mogplex webhook-backed coverage for the installed account or org

That is why a repo can appear in Projects yet still fail to participate in Triggers or installation-backed automations.

What “covered” unlocks in practice

When the right installation exists, Mogplex can do more than just list repos.

It can:

• receive webhook events for the installed owner
• offer that installation as a routing target in Triggers
• treat repos under that owner as eligible for App-backed workflows
• reconnect synced repos to the correct owner and installation metadata

What the app surfaces show

Inside Settings, each installation can show:

• the account or org name
• whether the scope is personal or org
• the synced repos Mogplex currently associates with that installation
• how many repos are mapped to it
• a direct manage link back to GitHub

This is the fastest way to answer the real operator question:

Do I have the right App installed on the right owner, or am I only seeing repos through OAuth?

How Mogplex keeps installation state fresh

The installations API is a little self-healing.

If Mogplex has GitHub App config and your GitHub username, but there are no stored installations yet, it can reconcile against GitHub again and hydrate the local installation records before returning the Settings view.

It can also refresh incomplete installation metadata, such as missing account login or target type, and then derive:

• a scope label like Org or User
• the GitHub manage URL for that installation

That is why the Settings page can often recover from stale installation records without asking you to reconnect everything manually.

The most reliable workflow

1. Connect GitHub in Settings.
2. Confirm the expected personal account or org appears in the installation list.
3. Sync repos into Projects.
4. Only after that, debug Triggers or Automations.

If you skip step 2, you can spend time debugging a routing problem that is really just missing GitHub App coverage.

Common symptoms of missing coverage

• the repo appears in Projects, but Triggers offers no useful installations
• mention or PR-triggered work never fires even though the repo is visible
• webhook-backed automation looks empty or unavailable for the owner you need
• the app appears connected, but Mogplex still behaves as if the repo is “outside” the GitHub App boundary

In this section

• Coverage and Triggerability explains the “repo is visible but not triggerable” setup model
• Repo Sync and Rebinding explains how repos are attached to installations and how stale bindings get repaired

Where installations show up in the product

• Settings is the main inspection surface
• Projects shows the repos that were imported or synced
• Triggers only offers installations that are actually available for webhook-backed routing
• Automations depends on installation-backed GitHub events

If routing or review behavior looks wrong, check installation coverage before you debug the agent or automation itself.