Reference
Repositories
Connect the source repositories SyftOS governs, so every AI-authored pull request becomes a governed change-review gated by a distinct human approver and sealed onto the tamper-evident audit chain.
What this area is for
The Repositories page is where you register the codebases SyftOS watches over. Once a repository is connected, pull requests opened by your coding agents are turned into governed change-reviews, and a status check on the merge holds the pull request until a human approves it.
The page also shows your governed-repository capacity: how many repositories you have connected against your plan's limit. Each connected repository consumes one slot; disconnecting one frees it again.
Connecting a repository
There are two ways to connect, depending on how your platform is set up.
-
Connect GitHub (recommended). Authorise
GitHub once, then choose a repository from the picker.
SyftOS sets up the webhook and the merge status check
for you. There is no token or secret to paste. The
picker lists the repositories you administer on GitHub;
you can search by
owner/name, and repositories that are already connected are shown as such and cannot be picked twice. -
Connect manually. The advanced
fallback, offered when GitHub OAuth is not configured or
you prefer not to use it. You supply the
organisation/owner, repository name and default branch
yourself, then paste a GitHub access token (with
reposcope) and a webhook signing secret, and add the webhook to the repository on GitHub by hand.
What you configure
When you connect a repository you set the rules SyftOS enforces. Sensible defaults are filled in, so adjust only what you need:
-
Coding agents to govern: the authoring
tools (for example
cursor,copilot,claude-code) whose pull requests become governed change-reviews. -
Protected branches: branch patterns
that cannot be merged into until a distinct human
approves (for example
main,release/*). - Off-limits paths: path globs that block any change touching them.
- Maximum change size: pull requests larger than this ceiling are blocked as un-reviewable.
- Advanced: the status-check name to mark required in branch protection, an optional residency zone, and (manual only) the GitHub app installation and repository IDs.
Each connected repository card shows its provider, default branch, registered status-check name, the configured rules, and whether its webhook secret and access token are configured — the secret material itself is write-only and is never shown again after you submit it.
Per-repository policy
Use Policy on a repository card to publish a policy version: policy-as-code over which coding agents may author which paths, the diff-size ceiling, secret scanning, danger-class escalation, the required CI checks and whether a distinct human approver is required.
Published policies are immutable. Editing does not change an existing version. It publishes the next one, so the full policy history is preserved. The editor opens showing the rules currently in force (the latest version, or the values captured when the repository was connected if none has been published yet), and each card lists its policy versions newest-first.
Disconnecting, permissions and audit
Disconnecting a repository stops it being governed and frees a governed-repository slot. It is graceful and history-preserving: a repository that already has governed change-reviews is soft-disconnected so its immutable history is retained, while one with no history is removed outright. Existing change-reviews and attestations always stay on the audit chain.
The entire surface (connecting, configuring, publishing policy and disconnecting) is gated by the repos.manage permission (Owner and Admin roles). Connecting a new repository additionally requires your plan to include code governance; without it you will see an upgrade prompt rather than the connect controls. The server enforces both, so cross-tenant access resolves as a 404, never a leak.