How it works
01 /
Require evidence from the expected App
The managed ruleset requires the Codex review gate and pins the check to the integration. Optional title and commit-message policies add their own App checks when configured. Publishing a similarly named commit status does not establish the same App-owned evidence.
02 /
Keep the base current
Strict base freshness prevents an older head from merging against a newer policy epoch. The ruleset requires pull requests, adds no extra approval count and allows initial branch creation. It has no bypass actors, including administrators or the automation App itself.
03 /
Reconcile as the repository changes
Default-branch pushes reconcile the managed ruleset and queue open PRs. Periodic reconciliation repairs drift and refreshes repository state. Configuration preview checks remain informational rather than silently becoming a mandatory rule.
A concrete example
Workflow example
Default branch ruleset
Required: codex/review-gate from the toolkit App
Optional: configured title and commit-message checks
Required: strict base freshness
Bypass actors: noneKnow the boundary
Current limits
GitHub plan capabilities constrain metadata rules. When commit-message metadata enforcement is unavailable, the toolkit records that state and explains the remaining Check Run enforcement. Ruleset reconciliation needs the App’s accepted repository permissions and does not make unrelated rules disappear.
Common questions
Can the merge command bypass its own ruleset?
No. Its installation token is subject to the ruleset, which declares no bypass actor.
Is the configuration preview check required automatically?
No. ci-toolkit/config is informational and is not added to this managed ruleset.
Runnerless / early access
Want this in
your workflow?
Get early access ↗Register interest and tell us what slows your CI down. The optional follow-up questions come after your email is saved.