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. For work bigger than one finding, see Missions.

From finding to pull request​

Click Fix on a finding — HYRAX-42 — or select several on Code health and use Fix (N), and Hyrax resolves exactly those findings, one pull request each. Every fix is scoped to one finding, so the PR you get is small, reviewable, and traceable back to what prompted it.

Fix is offered on findings only. Advisories and suggestions describe work that doesn't fit one code change, so they have no Fix; file them as an issue or mark them addressed instead.

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 where it can. When it finds a test command it can run, it runs your repository's own test suite against the edited code in its sandbox. It can do that for Python and Go, and for JavaScript or TypeScript tested with Vitest or Jest when the project's dependencies can be installed. Otherwise, testing the change is left to your repository's own CI — see Which tests run.
  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 the test and build step, 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. The diff review is the stricter of the two: if Hyrax's own review rejects the change outright, the fix is abandoned instead — no pull request opens, and the finding stays open. Both are adjustable per repo in the Fixes section of the repository's Settings (When pre-PR checks fail and When review rejects a fix).

Every Hyrax PR is easy to recognize and filter: by default the title leads with the finding reference in brackets — [HYRAX-42] fix(…): … — and the branch is namespaced — hyrax/fix-…. The title format is customizable per repository.

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, set Where fixes land to Commit directly in the Fixes section of its Settings: 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. And for a repository whose tests Hyrax can't run, a commit-mode fix can land without its tests having run first.

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.

Which tests run​

The verify step runs your repository's own tests and build, not a generic check, inside a sandbox (see available environments). It runs your tests there for Python and Go, and for JavaScript or TypeScript tested with Vitest or Jest when the project's dependencies can be installed. Hyrax works out how to test and build each repository from its own files.

When Hyrax can't run your tests — it found no test command for the project a change is in, the repository is in another language, or the suite needs a tool the sandbox doesn't have — it doesn't run them itself, and your repository's own CI is what tests the change. The pull request says so. If that CI fails on a Hyrax pull request, Hyrax picks it back up. With no CI, nothing runs your tests on the change, so review it with that in mind.

If CI fails​

On every plan, 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.

A finding closes when the PR merges​

Starting a fix doesn't close the finding — it closes as fixed only when the pull request merges. While the fix runs and its PR is open, the finding counts as Fix running and leaves Code health's default list; closing the PR without merging puts it back automatically. 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. For the full journey, see the finding lifecycle.

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 not fixed. Installing the App later doesn't change that: to run a fix, remove the repo and add it again with the App installed. See Public & private repositories.