Product · GitHub automation
Read-only by default. Write only if you ask.
A one-off scan tells you where you stand today. The connection stops it drifting back — every push re-checked, every fix confirmed gone.
Permissions
Exactly what you are granting.
Read this before you install anything — here or anywhere else.
Read-only is the default, and it is enough for every scan
It reads the code of the repositories you pick, and nothing else. It cannot push, open pull requests, change settings, or see repos you did not select.
Write is a separate grant, and it stays until you revoke it
Writing a fix needs a second, separate grant that you approve on GitHub's own screen. Be aware of what you are agreeing to: the grant is installation-wide and it persists — it is not asked for again per fix. You can revoke it from GitHub at any time, and scanning keeps working without it.
We never write to your default branch
A fix is committed to a branch named after the finding and left there. You review the diff and merge it, or you close it. Nothing we generate reaches your default branch on its own.
We would rather say this plainly than bury it
Plenty of tools describe write access as being asked for “per fix”. GitHub Apps do not work that way. The grant covers the installation and lasts until you remove it, and any product telling you otherwise is describing something GitHub does not offer.
How it runs
Four things it does once it is connected.
Scans run on our side. Close the tab, close the laptop, read the report when it lands.
- 01
Connect once, pick what it can see
Install the GitHub App on your personal account, an organisation, or both. Pick the repositories it can see. You can change that selection whenever you like, and removing a repo does not delete its scan history.
The app is currently unverified on GitHub's marketplace, so you will see GitHub's warning about that. It is accurate — we have not been through verification yet.
- 02
It re-scans on push
Every push to a branch you're watching queues a scan. It runs on our side with your browser closed, and you get an email when the report is ready.
Re-scans use the same rule pack version stamp, so a score that moved tells you the code changed — not that the rules did.
- 03
Fixes stay fixed, and regressions come back named
A finding you fixed disappears from the next report. One you reintroduced comes back with the same identity it had before, because a finding is identified by the rule and the code it matched — not by its line number.
This is also why a dismissal survives a refactor. Moving a function does not resurrect something you already decided about.
- 04
On Pro, it writes the fix
On Pro, VibeCheck writes the change itself, commits it to its own branch, and tells you what it did and what it deliberately left alone. Anything that needs a decision only you can make — rotating a live key, for instance — is described rather than attempted.
Fix verification, where we re-scan the branch to prove the fix worked, is on the roadmap and not shipped. We will not claim it until it is.
Score history
Watch the number move.
On Pro, every scan is a point on a line — the one view that shows effort rather than problems.
A scan that only partly completed is excluded from this graph rather than plotted low. A gap in the line is a scan that could not finish, and it is labelled as one.
Revoking
Leaving is one click, on GitHub's side.
Uninstall from your GitHub settings and the connection is gone immediately. Your scan history stays, and reconnecting the same repo restores it rather than starting a second copy.
Connect it and see.
Read-only, one repo, and you can pull the connection at any time from GitHub.