Skip to main content

How Hyrax works

Hyrax connects to your GitHub repositories, learns how each one works, finds real problems in the code, and does the work to fix them as pull requests you review. It also serves what it learned to your AI coding tools. There's no CLI to install and nothing to self-host: you work in the web app, or through the REST API and MCP server.

The loop​

Hyrax runs the same loop over every repository you connect:

  1. Connect. Sign in (continue with Google or an email code; existing GitHub sign-ins keep working). That gives you a workspace. Then connect your GitHub organization by installing the Hyrax GitHub App on the repositories you want covered. That links your repos and grants read access, plus the ability to open pull requests for fixes and missions. Your workspace starts with a Default area and, inside it, a Default space that holds every repository, so you can start right away and organize later. See Organizing work.
  2. Discover. Hyrax profiles each repository: its architecture, conventions, and engineering principles. It starts automatically when you add a repository on the web or through the REST API, unless something holds it back, such as your workspace's usage limits. Adding one through the MCP server or chat doesn't start it. If it hasn't run, start it from the repo's Discovery tab. An audit needs a finished discovery. See Discovery & AI agent context.
  3. Audit. When you run an audit, Hyrax reads your code and reports findings: concrete problems, each with the file and lines. Audits run when you start them, never on their own. See Running audits.
  4. Decide. Findings land on the Code health page. You choose what each one deserves: fix it now, file it as an issue in a project, keep it for later, or dismiss it. See Findings & Code health.
  5. Fix. Point Hyrax at a finding and it opens a pull request for you to review. See Fixes.
  6. Track the work. Work you plan to do lives in issues, inside projects. File them yourself, or file them from findings in one click. See Issues.
  7. Run a mission for bigger work. A mission takes one written instruction, plans the work in steps, and delivers one pull request. Missions are in beta; Hyrax support turns them on for a workspace on request. See Missions.
  8. Review. Hyrax reviews incoming pull requests automatically. Review is on by default for every repository you connect. See Pull request review.
  9. Connect your agents. Point the AI coding tools your team already uses, such as Claude Code, Cursor, and Copilot, at the Hyrax MCP server. They read the discovered context, your findings, and your issues live.

The loop is continuous. Re-run audits when you want a fresh look, fix as you go, and re-run Discovery after big changes. Your agents see the fresh context immediately.

What happens during an audit​

When an audit runs, Hyrax clones your repo at a specific commit into isolated, throwaway compute, analyzes it there, and deletes the working copy when the job ends. Raw source is not kept, and any staged copies on the processing infrastructure auto-expire within days. See Security for the full posture.

Inside that run, Hyrax combines fast, deterministic pattern matching with reasoning AI that reads your code the way a careful reviewer would, across security, correctness, maintainability, performance, architecture, and operations. The result is a set of prioritized findings, each pointing at the exact file and lines. See Audit tools & languages for what's covered and which languages are supported.

Re-running merges — it doesn't duplicate​

Re-running an audit doesn't pile up duplicates. Hyrax recognizes findings it has seen before and merges new results onto the existing ones, so your list stays clean and your decisions stick: dismiss something as a false positive, won't-fix, or out of scope, and re-running won't bring it back. You can audit as often as you like. See Findings & Code health for how each dismissal category behaves.

Because runs merge, your repo's finding total is cumulative: it grows as you audit more, not per run. Each audit is a deep sampling pass over your code. A re-run typically re-confirms most of what's already open and surfaces a few genuinely new findings, so two healthy runs of the same depth won't return an identical count. That's expected, not a defect: the union across runs is the point. A run's page shows its own story ("N new this run · M re-confirmed"), and Code health shows what is open across all runs, so a jump like "49 last week, 89 this week" reads as accumulation rather than a doubling of the same measurement.

Findings are evidence; issues are the work​

A finding records what Hyrax saw in the code. It is not a task. When you decide a finding is worth doing, file it as an issue in a project, where it gets an assignee, a status, and a place in your team's plan. The finding then shows Tracked with the issue's reference, so nobody files it twice. An audit never files issues on its own: what reaches your team's backlog is always your decision.

Fixes open pull requests​

By default, acting on a finding produces a pull request, never a silent edit. Hyrax makes the change in an isolated copy, runs your repo's own tests to verify it where Hyrax's sandbox supports them, double-checks the diff, and opens a pull request against your repo. Where it can't run your tests, your CI, if you have one, is what tests the change. A finding closes as fixed only when that pull request is merged. (A repo can opt into a commit-direct mode that skips the PR step. See Fixes.)

Where to go next​