GitHub App repository automation

The Redgold GitHub App can connect an onboarded repository to automated pull-request review and correction. This capability is a managed preview. App installation gives Redgold repository-scoped credentials; Redgold must also configure the repository binding and enabled automation modes before events are processed.

What the integration can do

An onboarded repository can enable either or both of these modes:

• Reviewer reads a pull-request diff, reports findings on the pull request, and observes the repository's normal CI results.
• Fixer addresses an accepted finding or a failing check on the pull-request branch, then lets CI evaluate the new commit.

The repository's branch rules and CI remain authoritative. A fixer cannot bypass protected-branch requirements, required checks, or merge approval policy. Default-branch changes still travel through a pull request.

Onboarding boundary

Installing the App by itself does not activate automation. Redgold confirms all of the following during onboarding:

1. The GitHub App installation covers the intended repository.
2. The repository is bound to the correct Redgold workspace.
3. Reviewer, fixer, or both are enabled for that binding.
4. The installation grants the minimum repository permissions needed for the selected mode.
5. Branch rules identify where automated commits and reviews are allowed.

Until that configuration is complete, repository events have no review or correction effect. Ask the Redgold operator for the repository's current status before relying on this path in CI.

Credential and ownership model

GitHub issues, pull requests, reviews, and commits are written as the installed App identity. Redgold mints short-lived installation credentials scoped to repositories selected in the installation; a user's personal GitHub token is unnecessary. Removing a repository from the installation or uninstalling the App revokes that repository access.

Webhook signatures are verified before an event is accepted. Repository identity is taken from the verified event and the configured binding. Redgold account credentials and GitHub installation credentials remain separate.

Typical pull-request cycle

1. A contributor opens or updates a pull request.
2. GitHub sends the signed repository event to Redgold.
3. The configured reviewer examines the current commit and reports findings.
4. The configured fixer can apply an eligible correction to the pull-request branch.
5. Repository CI evaluates the resulting commit.
6. A maintainer merges according to the repository's branch policy.

Automation can stop for missing permissions, an unmapped repository, a protected branch, an ambiguous correction, or an unavailable execution environment. The pull request remains the audit trail in each case.

Other control surfaces

GitHub App automation is useful for event-driven repository work. Redgold also exposes customer-controlled agent operations through the owner-scoped MCP tools and the authenticated /v1/agents/* REST routes. MCP mutations create approval requests. REST agent lifecycle calls operate only on agent slots already assigned to the authenticated caller.

Managed Redgold environments can additionally use the curated rac workflows in Assist agents with agent-cli. That surface is intended for operators and trusted agents with an assigned environment.