Set Up CI Sentinel Auto Fix in Ten Minutes

2026-10-22 · 6 min read

CI Sentinel runs your GitHub Actions on Codex Infinity runners, records every run, and can create a fix task when a build fails. This guide walks through a sensible first configuration using the public API.

What you get

Dedicated runners for your repository or organization.
Stored run status, logs, and failure metadata.
Optional fix tasks created automatically when CI fails.
Debounce and cancellation of superseded runs to save compute.

Create a sentinel

Create an API key in your account, then send a POST to /api/ci-sentinels with your key in the Authorization header. A compact configuration looks like this:

{"name":"my-ci","repo":"owner/repo","default_branch":"main","enabled":true,"runner_label":"codex-infinity","pool_min":0,"pool_max":4,"pool_idle_minutes":10,"auto_fix_enabled":true,"auto_fix_prompt":"Use Bun for install and test. Fix failing CI and open a PR with a concise summary.","auto_fix_branch_prefix":"ci-fix/my-repo","auto_fix_prs":true,"cancel_superseded":true,"debounce_minutes":5}

Size the runner pool

Set pool_min to 0 so idle repositories use no runners, and choose a pool_max that matches your parallel jobs. The pool_idle_minutes value controls how long a runner waits for work before it winds down. A small repository is comfortable with a max of two to four.

Register runners

Request a registration token with GET /api/ci-sentinels/{id}/runner-token, adding ?org=ORG_NAME for an organization. To provision machines, POST to /api/ci-sentinels/{id}/runners with a count, server type, location, and labels. Registration uses a short lived GitHub token, so there is no long lived secret to store.

Point workflows at the runner

In your workflow file, set runs-on to the sentinel's runner label. Jobs then execute on your Codex Infinity pool, and each run appears in the run list at GET /api/ci-sentinels/{id}/runs.

Tune auto fix

With auto_fix_enabled on, a failed run creates a task using your auto_fix_prompt. The auto_fix_branch_prefix keeps fix branches easy to find, and auto_fix_prs asks the agent to open a pull request you can review. Write the prompt with the same care as any task: name the tools, state the outcome, request a short summary.

Keep noise low

Use debounce_minutes so a burst of pushes produces one fix attempt, and turn on cancel_superseded so older runs stop when a newer commit arrives. Your queue then tracks the latest state of the branch.

A sample failure to fix cycle

A contributor pushes a change that breaks a unit test. The run fails on your Codex Infinity runner, the failure is recorded with its logs, and after the debounce window an agent task starts using your fix prompt. The agent reads the failing output, edits the code, reruns the checks, and opens a pull request on a branch beginning with your chosen prefix. You review one small diff rather than digging through logs.

Good habits

Start with one repository and review each fix pull request for the first week. Refine the prompt whenever a fix misses a convention, for example by naming your formatter or test runner. Keep the branch prefix distinct per repository so branches stay easy to filter.

Next step

Create your first sentinel from the dashboard or read the API docs. Start with one repository, watch a few failures turn into pull requests, then roll the pattern out to more projects.

Start with Codex Infinity or browse the full blog.

← Back to Blog