# GitHub App permissions The permissions Runzivo requests, what they support, and the controls customers retain. 6 connected Current status Today Repository access Follows the repositories you select Runner execution Live for organization repositories Personal-account repositories Not supported · use an organization Organization scopes Manage self-hosted runners · Read members AI write features Early access, off by default ## Availability Updated 21 October 2026: Runzivo supports organization repositories only and does not request the Administration permission. This replaces the earlier statement that personal-repository support was planned. After GitHub sign-in, connect a GitHub organization you own, including a GitHub Free organization, and select the repositories you want to use. The currently eligible runner labels are rzv-ubuntu-24.04-x64-2vcpu-8gb, rzv-ubuntu-24.04-x64-4vcpu-16gb, rzv-ubuntu-24.04-x64-6vcpu-24gb, rzv-ubuntu-24.04-x64-8vcpu-32gb, rzv-ubuntu-24.04-x64-16vcpu-64gb, rzv-ubuntu-24.04-x64-32vcpu-128gb. Creating a workspace does not add repository access: select each repository during the Runzivo Shared GitHub App connection. Installation linking, JIT runner provisioning, and runner lifecycle transitions support the available GitHub Actions flow. Runzivo runs jobs for repositories owned by GitHub organizations. Repositories owned by a personal account are not supported: GitHub only lets an app register a runner on a personal repository if it holds Administration: Read and write, and Runzivo does not request that permission. To use Runzivo with a personal repository, create a free GitHub organization and move or fork the repository into it. The AI pipeline builder and CI fix agent are built and in early access. They are switched off and are not available for customer use until they are enabled for a workspace. This page describes the requested permission contract. A requested permission is not evidence that a live App registration has received it. [See the GitHub App setup guide](https://runzivo.dev/docs/github-app/) ## Requested repository permissions - Metadata: Read. Supports GitHub App configuration, signed intake, and selected-repository authorization. - Actions: Read and write. Supports queued-job admission, job lifecycle transitions, run history and job logs. - Contents: Read and write. The early-access pipeline builder and CI fix agent read repository files and write workflow changes to a new branch. - Workflows: Write. The early-access pipeline builder and CI fix agent change workflow files. - Pull requests: Read and write. The early-access pipeline builder and CI fix agent deliver their changes as pull requests. - Checks: Read and write. The early-access CI fix agent reads the failed checks it is asked to fix. - Issues: Read. Requested for planned assistant context; no available feature uses it. ## Requested organization permissions - Self-hosted runners: Read and write. Organization runner reservation, JIT registration, and removal use this access. Same-job binding remains unresolved. - Members: Read. Planned membership-change handling needs minimum organization, member, team, and membership-change identifiers. ## Installation scope During installation, customers choose Only select repositories. That choice limits repository permissions to the selected repositories, and customers can add or remove repositories later in GitHub App installation settings. Selected-repository access does not limit the separate organization permissions. Self-hosted runners and Members are organization-level scopes, requested for the purposes described above. Runzivo does not request Administration, Secrets, Variables, Environments, Packages, or Deployments permissions. Existing installations do not receive a new permission automatically. If Runzivo ever requests one, GitHub requires each installation owner to approve it before Runzivo can use it. ## Why these permissions are requested The requested permissions cover the available runner flow and the early-access pipeline builder and CI fix agent. Runzivo does not request Administration. GitHub grants that permission broad control over repository settings, branch protection, collaborators and deploy keys, which a runner service does not need. If requested permissions change in the future, GitHub or the customer may require a new approval. Runzivo will not assume an earlier installation approves later permission changes. ## Writes and workflow control Contents, Workflows and Pull requests write allow the pipeline builder and CI fix agent to deliver workflow changes. Both are in early access and are not available to customers yet. The CI fix agent changes CI files only, opens a pull request from a new branch, never pushes to an existing branch and never merges. Runzivo registers runners at the organization level with the Self-hosted runners permission. Because it does not hold Administration, it cannot change repository settings, branch protection, collaborators or deploy keys. Any future customer-initiated write requires authenticated customer action, tenant and selected-repository checks, and an operation-scoped installation token narrowed to the repository and permissions where GitHub supports narrowing. Repository writes are limited to a branch and pull request in the authorized repository, with no branch-protection or ruleset bypass. The one exception: a workspace owner can opt the pipeline builder in to commit a workflow file directly, still subject to branch protection. A runner executes the workflow a customer selects in GitHub Actions. Workflow steps can read or modify repository data, access secrets GitHub makes available to that job, and trigger actions with the workflow's own credentials. The App permissions do not directly grant access to a live job environment, job token, or stored Actions secrets. Secrets in code, logs, artifacts, or changed workflow content remain a risk. ## Customer controls and records Customers control repository access in GitHub App installation settings by adding or removing selected repositories. Suspending or uninstalling the App stops new runner requests. A revoked or unselected repository is denied by the authorization boundary. Raw webhook bodies are retained only in memory long enough to verify the signature and route a delivery. They are not logged or retained. Planned event acknowledgements retain nothing. Current queued-job handling persists only delivery ID, job, installation, and repository IDs, action, labels, admission decision, reason, and timestamp. It does not persist raw payloads. The current delivery-audit table has no purge. Tenant-approved retention and deletion work is a launch blocker for onboarding and processing. Before enabling future collection, Runzivo must apply tenant-approved retention and deletion to webhook, membership, PR or issue discussion, run metadata, logs, and metrics data. The Privacy Notice is a working draft for newsletter and Early Access information. It does not set a retention period or deletion process for GitHub App delivery audits. This page states the current GitHub App record handling and launch blocker; contact Runzivo for questions about the draft notice. [Read the privacy notice](https://runzivo.dev/legal/privacy/) On this page and page tools