Using VIfix
Fixing issues
VIfix proposes fixes; you decide. Nothing changes until you click.
The fix flow#
Select a finding → Generate fix → review the diff and verification → Apply to local file (local scans) or Commit Fix to GitHub.
Rule fixes and AI fixes#
| Rule fix | AI fix | |
|---|---|---|
| Who writes it | VIfix's built-in fix for that rule | Anthropic or OpenAI, with your own key |
| Cost | Free | Counts against your monthly AI fixes |
| Best for | Common, well-defined issues | Anything that needs context from the file |
Set up a provider in AI fixes.
Verification#
Every patch is re-parsed and re-scanned before you see it. The panel (and the PR description) shows:
- whether the original finding is resolved,
- whether any new findings appeared,
- whether the changed files still parse.
Pull requests#
- Changes go into one commit on a new
vifix/fix-…branch. Your base branch is never pushed to, and existing branches are never overwritten. - If the file changed on GitHub since the scan, the PR is refused so you don't overwrite newer work. Local apply refuses if the file changed on disk.
- Pull requests need a Pro or Max plan and a token with write access (see permissions).
Guardrails#
Files VIfix will never edit
.github/ and CI config, .env*, lockfiles, Dockerfiles, .git, node_modules, and anything outside the project folder. (docker-compose files can be fixed: hardcoded secrets become ${VAR} references.) A patch may touch at most 3 files and about 400 lines.