Approve a guarded change
How the owner approves a PR that changes guarded paths: what the PR says, where to approve it in the app, and why an agent never can.
Some files decide what "passing" means: ModernCI's own .ci/ files, goldens (recorded expected output), each check's rules: files and whatever the branch file lists under guarded:. A change never settles those for itself. A PR that changes one is checked as usual, but it merges only after a person approves its exact head in the ModernCI app.
1. What the PR says
When a PR waits for approval, its ci status says waiting for a person's approval of this head, and its Details link opens the approval page. ModernCI also comments on the PR once, with:
- each guarded path the PR changes, and why that path is guarded (a check's
rules:, the branch file'sguarded:,.ci/or a golden); - who may approve: an owner or maintainer of the tenant, with their own passkey. The comment also says whether the branch file's
approve:istrue(every move into the target waits for approval) orfalse(only guarded paths do); - the link to the approval page for that exact head.
It comments again when the state changes:
- Approved: who approved, when, and which head.
- Approval stale: a new push came after an approval. The approval was for the old head, so it no longer counts, and the comment links the new head's page.
2. Approve it in the app
- Sign in to the app with your password. To add a passkey, open Profile (
/me#passkeys) and choose Add a passkey. You only need to do this once. - Open the link in the PR comment, or Approvals (
/approvals), which lists every PR that is waiting. - Read the diff of the guarded files on that page.
- Press Approve this head with your passkey, then touch Touch ID, Windows Hello or your security key.
The approval covers that one head. The PR merges once its checks allow. If someone pushes again, you approve the new head. To refuse, choose Reject, with a note. The author's agent sees your note.
From the host's own shell, a person can also approve with modernci call approve --repo <owner/repo> --from <branch>.
3. Never an agent
Owner-signed content is approved in the app by the owner, never on an agent's relay:
- An agent's token can't approve a guarded path, wherever the token was minted, even with a delegation.
approverefuses it, and an approval a delegate keeps never counts for a guarded path or.ci/. - The sign-in cookie alone can't approve either. Each approval takes a passkey touch for that one head.
- MCP never lists
approveorapprove_begin, so an agent's client never sees them.
A delegation (delegate) still lets an agent approve a PR that is held only by the branch file's approve: true, if it changes no guarded path.