Skip to main content

Fixes

Hyrax doesn't stop at telling you what's wrong — it ships the change as a pull request you review and merge. A fix turns one finding into a PR.

From finding to pull request

Point a fix at an observation — HYRAX-42 — and Hyrax resolves exactly that finding. Every fix is scoped to one observation, so the PR you get is small, reviewable, and traceable back to what prompted it.

How it works

For every fix, Hyrax:

  1. Makes the change. It reads the finding, the relevant files, and the surrounding code, then writes the edit.
  2. Runs your tests. It runs your repository's own test suite against the edited code. A change that breaks tests never ships quietly.
  3. Reviews the diff. It double-checks the work — does this resolve the problem, is it correct, does it introduce anything new? If not, it takes another pass.
  4. Opens a pull request. A branch, a diff, and a description, on GitHub. You review, request changes, and merge or close it. Unless you've switched the repo to commit-direct mode, Hyrax never merges for you.

If a change fails verification, the pull request still opens by default — flagged with a hyrax:verification-failed label and a warning callout, so you see what didn't pass before you decide whether to merge. What happens when a fix fails its checks is adjustable per repo in Fix Settings.

Every Hyrax PR is easy to recognize and filter: the title carries a [Hyrax] prefix and the branch is namespaced — hyrax/fix-….

Where the fix lands

By default, every fix arrives as a pull request. Hyrax pushes a branch, opens a PR with the change, and you review and merge — nothing reaches your code without sign-off. Optionally, Hyrax can also file a Linear ticket alongside each fix PR, with the two linked.

If you'd rather skip the PR step for a repo, its Fix Settings offer a commit directly mode: Hyrax merges the verified fix straight onto a branch instead of opening a pull request. Two flavors:

  • Straight to the base branch — each fix lands on the audited branch as soon as it passes verification.
  • Accumulate on a dedicated branch — fixes pile up on a branch you name (for example hyrax/fixes), and you merge it into the base branch yourself when you're ready to ship them.

Commit mode is available on every plan; changing it requires repo-management permission in your workspace. One trade-off to know: in commit mode a fix that fails verification is always abandoned — there's no pull request to carry a warning.

Large changes

A fix is kept to a reviewable size, so you always get a diff you can read. If you have genuinely large work, break it into several smaller fixes instead of one sweeping change.

Your tests run

The verify step runs your repository's own tests and build, not a generic check. Hyrax detects how to test and build most repositories automatically. When it can't, set the Test command and Build command explicitly in the repository's Fix Settings — set once, used by every fix.

If CI fails

On Pro and Team, when your CI fails on a Hyrax fix PR, Hyrax picks the failure back up and revises the change — up to a limit, then it leaves the PR for you. The goal is to clear obvious misses automatically, not loop forever. On Free, a fix PR that fails CI is yours to finish: review the failure and update the branch like any other PR.

A finding closes when the PR merges

Spawning a fix doesn't close the observation — it stays in its actionable new state while the job runs and the PR is open. The observation closes as fixed only when the pull request merges. Close the PR without merging and it stays open. See Findings & suggestions.

Once the PR is open, the finding is handed off — Hyrax's job was to open the PR, and the rest is your review. It leaves your active Findings list and appears on the Completed page under Open pull requests, so what's left in Findings is what still needs a fix started. It isn't gone: close the PR without merging and the finding comes back to the active list automatically; merge it and the finding closes as fixed. If the repository has a Linear integration, the fix PR's link is also posted on the finding's Linear ticket, so the trail from finding → ticket → PR is one click in either direction.

Plan availability & GitHub App

Fixes are on every plan.

A fix writes back to your repo, so it needs write access through the Hyrax GitHub App. A public repo added by URL can be audited, profiled, and reviewed, but install the App on the upstream org to run a fix. See Public & private repositories.