Repository access: clone the repo, open the PR
A live patch is a temporary bridge; the permanent fix lands as a pull or merge request in your own repository. That is the entire reason Sarcio touches your Git host — to clone the repo and open the PR. It never reads your other repositories, never touches org or admin settings, never changes your CI configuration (it only dispatches a build for a site you opt into remote builds), and never deletes anything.
Recommended on GitHub: the Sarcio GitHub App
The Git host connection is a workspace connection: the identity Sarcio opens PRs and posts checks as. On github.com, an owner installs the Sarcio GitHub App on the repositories they pick. Sarcio then acts as sarcio-ai[bot], a teammate can review and approve its PRs, it keeps working when people leave, and nothing long-lived is stored. A workspace whose repositories span several organizations installs it once per organization. Only workspace admins can install or remove it.
Sarcio GitHub App
Installed by an owner on an organization or user account, on all repositories or only the ones they pick. Acts as sarcio-ai[bot].
| Scope requested | What it grants, and why | Access |
|---|---|---|
Contents — Read & write | Clone the repository and push the fix branch. | Write |
Pull requests — Read & write | Open the pull request that carries the permanent fix. | Write |
Checks — Read & write | Post sarcio/approval as a check run on the fix branch head, and read your CI result for the dashboard build chip. | Write |
Commit statuses — Read & write | Read commit statuses from CI that reports through them, for the build chip. | Write |
Actions — Read & write | Dispatch the workflow that builds a module patch in your CI, for sites that use remote builds. | Write |
Metadata — Read-only | Required by GitHub for every app. | Read |
No long-lived secret is stored for your workspace: Sarcio keeps only the installation id, the account and the repositories it covers, and mints a one-hour installation token when it needs one. Installing asks you to authorize the app once, so Sarcio can confirm your GitHub account can see that installation; that user token is revoked straight away and never stored. Suspend or uninstall the app on GitHub at any time; Sarcio stops using it when GitHub reports the change, or at the latest the next time it asks GitHub for a token.
Recommended elsewhere: a bot, project or repository access token
On GitLab and Bitbucket, and on GitHub where the app is not an option, give the connection an identity of its own. A bot token reaches only the repositories it was made for, its PRs read as Sarcio's rather than a teammate's, a teammate can review and approve them, and it keeps working when people leave.
GitHub
A fine-grained personal access token on a dedicated bot account, limited to the repositories Sarcio patches.
| Scope requested | What it grants, and why | Access |
|---|---|---|
Contents — Read & write | Clone the repository and push the fix branch. | Write |
Pull requests — Read & write | Open the pull request that carries the permanent fix. | Write |
Commit statuses — Read & write | Set the sarcio/approval status on the fix branch head. | Write |
Checks — Read-only | Read your GitHub Actions result on the PR for the dashboard build chip. | Read |
Actions — Read & write | Only if a site uses remote builds: dispatch the workflow that builds the module patch in your CI. | Write |
Metadata — Read-only | Added by GitHub to every fine-grained token. | Read |
Use this where the Sarcio GitHub App is not an option: GitHub Enterprise Server, or an organization that does not allow apps. On save, Sarcio calls GET /user to see who owns the token. A machine user is an ordinary user account, so it is badged Personal, which is expected for a dedicated one. Sarcio also reads each site repository (GET /repos/{owner}/{repo}) to warn when the token can't reach or push to it, and reads the token's expiry from the github-authentication-token-expiration header to remind admins 14 and 3 days ahead. The token is envelope-encrypted at rest and never shown again.
GitLab
A project access token with the Developer role, named Sarcio so merge requests read clearly.
| Scope requested | What it grants, and why | Access |
|---|---|---|
api | Open and update the merge request, set its sarcio/approval commit status, read its pipeline result, and run remote-build pipelines. | Write |
write_repository | Clone the project over HTTPS for module drafts. | Write |
A project access token creates a bot member of one project; a group access token covers a group. On GitLab.com both need a paid tier (self-managed GitLab has them on every tier). The fallback is a dedicated bot user's personal access token with the same scopes. Tokens expire (at most a year on GitLab.com), so plan to rotate. On save, Sarcio calls GET /user and reads bot: true to badge it Bot token, reads the token's scopes and expiry from GET /personal_access_tokens/self (warning when api is missing), and its role on each site project from GET /projects/:id (warning below Developer; Maintainer only matters when protected branch rules cover Sarcio's branches). Admins are reminded 14 and 3 days before expiry. Envelope-encrypted at rest.
Bitbucket
A repository access token, named Sarcio so pull requests read clearly.
| Scope requested | What it grants, and why | Access |
|---|---|---|
Repositories — Read & Write | Clone the repository, push the fix branch and set its sarcio/approval build status. | Write |
Pull requests — Read & Write | Open the pull request that carries the permanent fix and read its build statuses. | Write |
Pipelines — Read & Write | Only if a site uses remote builds: run the custom pipeline that builds the module patch. | Write |
A repository access token reaches one repository and acts as its own bot. Project and workspace access tokens cover more repositories but need Bitbucket Premium. On save, Sarcio calls GET /2.0/user. Access tokens cannot call it, so a refusal means Bot token. It then reads each site repository and lists one pull request, taking the token's scopes from the x-oauth-scopes response header, and warns when repository:write, pullrequest:write (or pipeline:write, for remote builds) is missing. Bitbucket reports no expiry, so enter it on the token form to get reminders. Envelope-encrypted at rest; revoke it in the repository settings.
Who owns the token
When an admin saves a token, Sarcio asks the provider who it belongs to, and badges the connection Bot token, Personal or Owner unknown. The check reads identity only and needs no extra scope: GitHub and GitLab GET /user, Bitbucket GET /2.0/user (access tokens can't call it, so a refusal means a bot token). It is best-effort: if the provider can't be reached, the token still saves as Owner unknown. The badge is a label for you, never an input to what Sarcio is allowed to do.
Personal connection (quick start, not recommended for production)
Connecting over OAuth authorizes Sarcio as the person who clicks Connect. It is the quickest way to try Sarcio, but the OAuth scopes below reach every repository that person can, PRs and commits appear as them, and the connection stops working if they leave. It is badged Personal, with a warning in the dashboard.
GitHub
Connect GitHub over OAuth, as the person who authorizes it.
| Scope requested | What it grants, and why | Access |
|---|---|---|
repo | Clone your repository, open the permanent-fix pull request on it, set the sarcio/approval status check and read your CI result on it. | Write |
GitHub's OAuth repo scope is coarse by design — it is the narrowest single scope that permits push and pull requests on private repositories, and it reaches every repository the authorizing person can. PRs and commits appear as that person, and the connection is badged Personal. Prefer the Sarcio GitHub App or a bot token above. Either way the token is envelope-encrypted at rest and never shown again.
GitLab
Connect GitLab over OAuth, as the person who authorizes it.
| Scope requested | What it grants, and why | Access |
|---|---|---|
api | Open and update the merge request that carries the permanent fix, set its sarcio/approval commit status and read its pipeline result. | Write |
read_repository | Clone the repository over HTTPS to build the fix. | Read |
write_repository | Requested alongside api; branches and commits themselves go through the API. | Write |
Reaches every project the authorizing person can, and merge requests appear as them, so the connection is badged Personal. The application is registered as Confidential. Access and refresh tokens are envelope-encrypted at rest and refreshed automatically before expiry; remove the connection on the Integrations tab to delete them.
Bitbucket
Connect Bitbucket over OAuth, as the person who authorizes it.
| Scope requested | What it grants, and why | Access |
|---|---|---|
Account — Read | Read the connected account name to label the credential in your dashboard. | Read |
Repositories — Read & Write | Clone the repository, push the fix branch and set its sarcio/approval build status. | Write |
Pull requests — Read & Write | Open the pull request that carries the permanent fix and read its build statuses. | Write |
Covers every repository the authorizing person can reach, in every workspace, and pull requests appear as them, so the connection is badged Personal. Bitbucket scopes live on the OAuth client (formerly called a consumer), registered as private with the authorization-code grant (which adds a refresh token). Tokens are envelope-encrypted at rest and refreshed before expiry.
What Sarcio writes to your repository
One fix branch, one pull or merge request, and one approval status per fix (a check run when the GitHub App opened the PR, a commit status otherwise). The PR body carries the report context, who approved the fix, and a link to the report in Sarcio. The sarcio/approval status reads, for example, Approved in Sarcio by Ada L. and Bo K. · elevated risk. Every commit Sarcio makes ends with one Approved-in-Sarcio-by: Ada L. trailer per approver. Approvers are named, never by email, because fix PRs can land on public repositories, and they are never added as Co-authored-by, because approving a fix isn't writing it.
Before any clone, Sarcio runs an API preflight against the credential — a repository the token cannot see is refused outright, rather than failing mid-build. For the strictest posture, opt a site into remote builds: the module patch builds inside your own CI/CD and only the validated artifact returns, so no build runs on Sarcio's infrastructure. Drafting the fix still reads the relevant source through your connection.
See it from the inside.
Spin up a workspace and every one of these connections is a click away — with the exact scopes shown before you approve them.
Create a workspace