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. Sign up → 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:

Permission	Access	What we do with it
Pull requests	Read & write	Read PR diff/files; post reviews + inline comments
Contents	Read	Fetch file contents at PR head SHA for context
Metadata	Read	Default; required by all GitHub Apps
Issues	Read & write	Reply to @sigilix mentions
Checks	Read & write	(Optional) Publish a check run alongside the review
Workflow runs	Read	(Optional) Diagnose CI failures via workflow log analysis

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. Add as many as your plan covers from the GitHub App settings page; reach out to support@sigilix.ai with any questions.

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