GitHub

Sigilix is distributed as a GitHub App. This page covers the deep details of how it interacts with GitHub.

​

Installation flow

See Installation for the full step-by-step. In short:

1. Join the private beta → authorize OAuth
2. Click “Install Sigilix on a repository”
3. Choose org + repo selection
4. GitHub redirects back to Sigilix with the installation ID

​

Permissions deep dive

Sigilix requests these GitHub permissions: Anything not listed is not accessed:

• ❌ Code outside opened PRs (we don’t scan main branch on push)
• ❌ Releases, deployments, secrets, packages
• ❌ Admin or billing surfaces
• ❌ Code from repositories where Sigilix isn’t installed

​

Branch protection compatibility

Sigilix is designed to play well with branch protection rules. You can require a Sigilix review status check before merging:

​

Required status check

After a Sigilix review, the corresponding check run is created with conclusion:

• success — verdict is APPROVE
• failure — verdict is REQUEST_CHANGES with at least one Critical finding
• neutral — review couldn’t run (rate limit, internal error)

To require this check before merge:

1. Repository → Settings → Branches → Branch protection rules
2. Add a rule for main (or your default branch)
3. Check “Require status checks to pass before merging”
4. Search for Sigilix and select it

Now PRs can’t merge until Sigilix’s check is success. If a developer pushes a fix, Sigilix re-reviews automatically and updates the check.

​

Required reviewers

Sigilix’s verdict (APPROVE or REQUEST_CHANGES) counts as a GitHub PR review. If your branch protection rule requires “1 approving review,” Sigilix’s APPROVE counts toward that.

​

CODEOWNERS interaction

If your repo has a CODEOWNERS file requiring a specific reviewer, Sigilix’s review doesn’t replace that requirement. Both the human reviewer and Sigilix’s verdict apply.

​

Multi-repo install

Most orgs install Sigilix on multiple repos. During the private beta there are no per-tier repo caps — repo access is provisioned per account; reach out to support@sigilix.ai if you want Sigilix on more repos. To add a repo to an existing install:

1. Open GitHub App settings
2. Find the Sigilix install → Configure
3. Add the repo to the selection
4. Save

The next PR opened on that repo will be reviewed.

​

Per-repo configuration

sigilix.json lives at the root of each repo. Different repos can have different configurations — narrower pathFilters on a marketing site, stricter rules.security on a payment service, etc. There’s no org-level config. If you want shared rules across repos, commit the same sigilix.json to each repo (or generate it from a shared template).

​

Webhook delivery

Sigilix subscribes to these events:

• pull_request — opened, synchronize, reopened, ready_for_review
• issue_comment — created (filters for @sigilix mentions)
• pull_request_review_comment — created (filters for inline mentions)
• workflow_run — completed (only for failure-triage; opt-in)

GitHub’s webhook delivery has at-least-once semantics. Sigilix uses a (prNumber, headSha) dedupe key in KV to prevent duplicate reviews on redelivered webhooks. If a delivery fails (Sigilix’s HTTP endpoint returns non-200), GitHub retries with exponential backoff for up to 24 hours. After that, the delivery is marked failed and you can manually redeliver from the GitHub App webhook log.

​

GitHub Enterprise Server

Sigilix supports GitHub Enterprise Server (GHES). The webhook URL is configurable per-installation; reach out to support@sigilix.ai to set up a private installation against your GHES instance.

​

Token rotation

Sigilix mints installation tokens on demand using the App’s private key. Tokens expire after 1 hour and are not stored — they’re minted fresh for each review. If you suspect Sigilix’s private key has been leaked, rotate it from the GitHub App settings page. Old tokens become invalid; Sigilix’s deployment picks up the new key automatically (after a re-deploy, in dev; immediately, in production).

​

Read next