---
title: "Fix it for me, with a receipt | ShipSafe"
description: "On a subscription, one click sends the fixes for a scan to your GitHub for you to approve, with a receipt of what was fixed and re-checked, what is still there, and what was not attempted."
doc_version: 2026-09-17
last_updated: 2026-09-17T12:57:39.845Z
canonical: https://ship-safe.co/docs/fix-it-for-me
---

# Fix it for me, with a receipt | ShipSafe

● Fix it for me

# Fix it for me, with a receipt.

On a subscription, one click sends the fixes for a scan to your GitHub for you to approve. Nothing changes until you approve it. The receipt says what was fixed and re-checked, what is still there, and what was not attempted.

## What it is

On a subscription, every scan comes with a fix prompt you can paste into the tool that built your app. This is the other option: ShipSafe writes the fixes itself, re-checks each file it changed, and sends the changes to your GitHub together, for you to approve. It is a proposal, not a change. Nothing in the code your app runs from moves until you approve it — in ShipSafe or on GitHub — and there is no setting that lets ShipSafe approve for you.

It runs when you click, and only then. Nothing is scheduled, and no person at ShipSafe reads, runs, builds or tests the change.

## Who has it

The subscription plans: Solo ($19/mo), Shield ($29/mo) and Growth ($49/mo). It is not part of the Free plan or the one-time Pro Audit. See [pricing](https://ship-safe.co/pricing) for the full comparison. A fix run does not spend one of your AI scans.

## Before you click

- **A scan of a GitHub repository, with findings.** The button sits on the scan page once the scan is done. It is not offered on a folder scanned from the CLI or on a live URL scan, because there is nowhere to send the changes.
- **A GitHub account that can write to that repository,** connected to ShipSafe. Connect it from the scan page when it asks, or from Settings. If you cannot write to it, there is nowhere for the fixes to go, and the run stops without changing anything.

NOTE· What the GitHub permission covers

The GitHub account connection (OAuth) has no read-only scope for private repositories, so the permission it asks for covers writes too. ShipSafe writes with it in two places: when you send the fixes, it creates a new branch — a separate copy of your code inside your own repository — and opens one pull request from it, GitHub's page for approving a change. It writes to your default branch — the code your app is built from — only once, and only when you approve that change in ShipSafe: it then applies just the one change, using the same GitHub access, so it lands under your own account. ShipSafe never approves the change for you; approving is your own click — in ShipSafe, by you, signed in; or on GitHub, by you or by anyone with write access to the repository.

## What one click does

Before you ever click here, the scan already looked once: a first automated reviewer reads as many findings as its budget and time allow, and a finding it is confident has no vulnerability is then, budget and time allowing, checked by a second, independent reviewer that tries to show it is exploitable in that file. Only when both agree it is not real is that finding not shown and not counted — not fixed and not sent; when that second check cannot run, the finding stays shown, counted, and eligible for a fix like any other. What one click does is take on everything that is left.

1. **Fixing and re-checking.** ShipSafe reads each file with a finding and writes a fix for every finding it can. Where a fix can be computed it is computed — an integrity hash for a script loaded from a public CDN, for example. The rest are written by a model, up to 5 tries per file. An automated reviewer reads every change a model wrote and refuses one that does not address the finding or looks likely to break something; a computed fix is not reviewed — its value is read from the resource itself, and its line on the receipt says so. When the reviewer's reason points at another file — a database policy, a shared check the fix truly belongs in — a later try reads that file too and can change both together. Then each changed file is re-checked with the same checks the scan used. While this runs, nothing in your code has changed.
2. **Sending to GitHub.** The changes go to your GitHub together, as one page for you to approve.
3. **Fixes sent to GitHub.** The receipt appears on the scan page and, when notifications are on, in an email. On a private repository the page on GitHub also names what is still there and what was not attempted, and the dependency updates; the fixed and could-not-be-re-checked findings are counted there and named on the scan page. On a public one the page carries the counts and a link back to the scan page. From here it is waiting for your approval, and nothing changes until you approve it.

The fix prompt stays where it was, for anyone who would rather apply the changes themselves.

## Approving

There are two ways to approve, and both are your own click. Nothing in your code changes until you make one of them.

- **Approve in ShipSafe.** Signed in, on the scan page: ShipSafe applies that one change to your default branch for you, using the GitHub access you granted, so it lands under your own account. It is pinned to the exact change the receipt describes — if that change was altered on GitHub since, no longer fits your code, or your repository requires a review or a check first, GitHub refuses to apply it, ShipSafe tells you plainly, and you can still approve on GitHub yourself. Where ShipSafe cannot tie your click to the exact change the receipt covered, it declines the same way and asks you to re-scan and send the fixes again.
- **Approve on GitHub.** Open the page on GitHub and approve the change there yourself, exactly as you would any other change to your repository.

Either way, ShipSafe does not build or test the change first, and each approval covers one change. There is no setting that lets ShipSafe approve without you, and an email never approves anything — the button in the completion email only opens your scan page, signed in.

Declining is just as simple: close the page on GitHub, or leave it alone. Nothing is deleted while you decide. If a fix is still waiting for your approval, starting another run on that scan is refused and points you back to it. If you decline it on GitHub or close the page without approving, the next run replaces it with new fixes.

## The receipt

A receipt is three counts and up to five lists: the findings behind each count, named, and two more. The counts add up to the number of findings the run took on, so there is no difference left for you to guess at.

Example · a finished run's email, with invented files

Your fixes are on GitHub

Waiting for your approval. Nothing changes until you approve it.

Review and approve in ShipSafeSee it on GitHub

- 7fixed and re-checked
- 3still there, needs your eyes
- 1could not be re-checked; re-scan after you approve

11 findings across 6 files.

Still there, needs your eyes

- Rate limiting missing on a login route (`src/app/api/login/route.ts`) — still detected after 3 attempts
- User id read from the request, not the session (`src/app/api/orders/route.ts`) — still detected after 2 attempts
- Auth check bypassable via a crafted header (`src/middleware.ts`) — still detected after 5 attempts

Could not be re-checked; re-scan after you approve

- Verbose error returned to the client (`src/app/api/webhooks/route.ts`)

Not attempted

- Script loaded from a CDN without an exact version (`public/index.html`) — needs a value a text edit cannot compute
- vendor/legacy-bundle.js (too large for the model to read in one pass; not attempted)

Dependency updates to run

- next: upgrade to 15.2.4 — run `npm install next@15.2.4`

### The three counts

- **fixed and re-checked** — the same check that flagged the finding was run again on the changed file, and no longer detects it. That is what “fixed” means on this page. It does not establish that the vulnerability is gone, and it says nothing about files the run did not touch. Read the change before you approve it.
- **still there, needs your eyes** — the run tried and the re-check still detects the finding. The scan page and the email name each one, with how many attempts it got; so does the page on GitHub, on a private repository. What was changed may still be worth keeping, but this finding is not closed, and the receipt will not say it is.
- **could not be re-checked; re-scan after you approve** — the file was changed, but the re-check did not run or did not finish in time. Nothing is claimed either way. After you approve, run a new scan and it will tell you.

### The other lists

- **Not attempted** — findings this run could not attempt at all: no file location to patch, a value a text edit cannot compute (a script with no exact version to pin), a file too large for the model to read in one pass, or one that changed since the scan. A finding the reviewer tried and refused every round is not here — it is “still there, needs your eyes” instead, since the run did try.
- **Dependency updates to run** — package updates, as commands you run yourself. ShipSafe does not edit lockfiles, so there is nothing to approve for these.

The scan page holds every line the run recorded of every list (the first 500 of each), the first few in view and the rest behind “Show all”. The email prints the first 3 of each list but the fixed one and says how many more are on the scan page; on a private repository the page on GitHub lists up to 30 of each, then counts the rest.

## Running it again

A second click — on the same scan, or on a new scan of the same repository — is told what the previous run learned. For a finding that was still there, the one line where the re-check last saw it (kept on the run record with any secrets redacted). For a change the reviewer refused, the reviewer's reason. The receipt says so in one sentence:

> 2 findings carried over from the previous run: this run was told what it learned about them.

A finding the previous run also left still there is labelled “still there after more than one run, needs your eyes”. Nothing runs on its own: a second run happens only when you click again.

Where the earlier fixes for that scan are still waiting for your approval, a second click is refused and points you to them. Where you closed them without approving, the second run starts over: ShipSafe moves its own branch back to where your default branch is and writes the new fixes there, so the fixes you declined are replaced. A second run never touches your default branch; only your approval does.

## The email

A run takes minutes, so when it ends you get one email with the receipt: the headline, the counts, every list but the fixed one (what was fixed is the change itself, on GitHub, and the scan page names it), a “Review and approve in ShipSafe” button that opens your scan page, signed in, and a “See it on GitHub” link to the change on GitHub. The subject of the example above would read “Your fixes are on GitHub — 7 fixed, 3 still there, 1 could not be re-checked”. A run that went through every file and had nothing to send — every change refused — sends “Your fix run finished with nothing to send” with its reasons and lists. A run that could not finish sends “Your fix run could not finish” with the reason, and a run that stops reporting partway through is eventually ended by ShipSafe and sends the same. The email notifications switch in Settings turns these off with the rest.

## Limits

- One run at a time per scan.
- 1 run in flight per account at a time: a click while your run on another scan is still going is refused until that run ends.
- 5 starts per hour per account, and 10 per rolling day.
- A start past a limit is refused with a message saying so; nothing in your code changes.

## What ShipSafe does not do

- It does not build or test the changed code, and does not warrant that a change fixes the finding. Reviewing and testing before you approve is yours to do.
- No person at ShipSafe reads, runs, builds or tests the change before it is sent.
- It never approves for you and never approves on a schedule. It writes to your default branch only when you approve the change in ShipSafe; approve it on GitHub instead and GitHub applies it there, without ShipSafe writing anything.
- It re-checks only the files it changed. A receipt says nothing about the rest of your code, and is never a claim that every finding was fixed.

The [Terms](https://ship-safe.co/terms#ai-generated-fixes) say the same in full.

## Public repositories

If the repository is public, the page on GitHub is public too: anyone can read the changes. So on a public repository the description of that page carries only the three counts and a link to your scan page. The full receipt — every finding and where it stands, the names and file paths of what the run did not fix, the reviewer's reasons — stays in your signed-in account, and, every list but the fixed one, in the email when notifications are on. On a private repository the page on GitHub also names what is still there, what was not attempted, and the dependency updates, with any detected secret value redacted; the fixed and could-not-be-re-checked findings are counted there and named on the scan page. If you would rather even the changes stayed between you and ShipSafe, apply the fix prompt yourself instead.

[← PreviousGetting Started](https://ship-safe.co/docs/getting-started)[Next →CLI Reference](https://ship-safe.co/docs/cli)

## Sitemap

Every page of this site, in markdown: [https://ship-safe.co/sitemap.md](https://ship-safe.co/sitemap.md)