# Auto-fix PRs

# Auto-fix PRs

Finding a bug is half the job. inline can also *fix* it — opening a separate, stacked pull request that patches selected findings, and **verifying the patch by actually compiling and testing it in a sandbox** before presenting it. Nothing lands in your branch unless you merge it.

> Two distinct fix engines share this pattern. This page covers **review auto-fix** (fixing review findings). For remediating confirmed dependency vulnerabilities, see **[Security auto-fix](./security-autofix.html)**.

## The workflow

After a review posts, you choose which findings to fix — from the portal's review page, from a checkbox on the PR comment, or with a command. inline then delivers a fix by the least-intrusive route that works:

1. **A native GitHub suggestion** for a trivial single-hunk change.
2. **A stacked fix PR** — one commit per finding, on a branch opened against your PR's head branch. Merge it and the fix folds into your original PR.
3. **A patch artifact** you can download, for fork PRs inline can't push to.

It never commits directly into the author's branch.

## Patch, then prove it

The fix runs in an isolated [sandbox](./sandbox.html):

1. Clone the PR head, install dependencies, and record a **baseline** compile + test result.
2. For each finding, an agentic loop powered by Claude reads the code and edits files. If it can't fix something safely, it says so and skips it.
3. **Compile gate:** a fix is rejected only if it *regressed a check that was green at baseline* — otherwise the working tree is reset. Only files the agent actually changed are committed.
4. The test suite runs **once at the end**. A fix is marked *verified* only if tests didn't regress and it compiled; if the repo has no runnable checks, inline is honest and marks it *unverified* rather than pretending.

Progress streams live to the portal and to a sticky PR comment (generating → verifying → pushing → ready).

## What you get

Each fix run records, per finding, the patch (unified diff, additions/deletions), its verification status, and the commit. The fix PR's description summarizes what changed and how it was verified. You review it like any other PR — the point is that inline did the mechanical work and *checked its own work* first.

## Enabling & limits

Off by default. Enable with **Auto-fix** in [review config](./review-config.html) (per-repo over workspace). Each run is bounded — it fixes a capped number of findings and is time- and cost-budgeted, so a run always terminates cleanly rather than running away.

Requires the GitHub App to have **Contents: write** and **Pull requests: write**. Fork PRs fall back to a downloadable patch served by a share link.