What happens when SixthWall scans your pull request

People are rightly careful about which apps they install on a repository. This post walks through exactly what the SixthWall GitHub App does, so you can decide with the facts rather than the marketing. The install link is one click, and so is uninstalling.

#What it asks for and why

The App requests three repository permissions.

• Contents: read. To download the files a pull request changed. Without this it cannot scan anything.
• Pull requests: read and write. To read the diff and to post one comment with the findings. It never approves, requests changes, merges or closes anything.
• Checks: read and write. To create the "SixthWall" check you see in the merge box, with annotations on the changed lines.

It subscribes to three events: pull request activity, installation and installation-repositories. It does not receive pushes to branches without a pull request, issues, discussions or anything else.

#The sequence, step by step

1. You open a pull request (or push to one, reopen it, or mark a draft ready). GitHub sends a signed webhook to sixthwall.dev. The signature is checked against the App secret before anything is read, and a delivery that GitHub resends is ignored by its id.
2. A job is queued. If you push again before the previous job ran, the old job is replaced. If the previous scan is still running, its check is cancelled so you never see two results for one commit.
3. The worker fetches only the changed files, at the pull request's head commit, through the GitHub API. The repository is never cloned. Files land in a temporary folder on the server, are scanned, and the folder is deleted when the job ends, whether it succeeded or failed.
4. The same engine as the CLI runs. The 68 rules, the tree-sitter parsers and the taint tracking are the @sixthwall/core package you can run on your laptop. There is no model in the loop; the same code produces the same finding every time.
5. Your project's config is honoured. The worker reads .sixthwall.yaml and .sixthwall/ignore from the head commit. A rule you ignored locally, a path you excluded, a finding you reviewed and dismissed: all silent in the pull request too.
6. Findings are mapped onto the diff. A finding on a line this pull request added or changed becomes an annotation on that line. A finding in a changed file but on a line the pull request did not touch is listed under "pre-existing" in the comment, never annotated. You are not blamed for code you did not write.
7. The check is decided. It fails only if a finding's severity is in the repository's block_on list, which is critical by default. Anything else leaves the check neutral, so a medium finding informs you without blocking the merge.
8. One comment is posted and then updated in place on every push. It lists each finding with the smallest patch, a safer alternative where the pattern itself is the problem, and a prompt to paste into Claude Code, Cursor or whichever tool wrote the code. No new comment per push, no noise.

#What is stored and what is not

Stored: the file path, line number, rule id, severity, the Fix Pack text, the score, and the pull request number and commit it belongs to. Never stored: your source code, the diff, or the file contents. The dashboard and the public project page are built entirely from the first list.

If you uninstall the App, the installation is marked deleted and scans stop at once.

#Making it quiet without turning it off

A security check you have to override every day gets disabled. Three ways to keep SixthWall useful and quiet:

• .sixthwall/ignore for a specific finding you reviewed and accepted. One line per finding, path/to/file.ts:AI-AUTH-001, with a comment above saying why. The App reads this file, so the review happens once.
• exclude in .sixthwall.yaml for folders that are not your production code: fixtures, generated clients, vendored code.
• block_on in the repository's dashboard settings if you want high findings to fail the check too, or only critical ones to begin with.

#Full audits and the badge

A pull request scan looks at what changed. From the repository page in the dashboard, "Run full audit" scans the whole default branch the same way (downloaded as an archive, never cloned, deleted afterwards) and produces a self-contained HTML report you can share or print.

Once at least one scan has run, the badge at sixthwall.dev/api/badge/gh/<owner>/<repo> shows the verified score from the latest scan. Until then, the badge is the project's own statement, and the page says so. Put it in the README if you want people to see that the code is checked, and to see when it stops being checked.

#Why this design

The constraints were: never hold source code, never post more than one comment, never fail a check for something the author did not change, and produce the same answer the author would get locally. Everything above follows from those four. If something in the behaviour surprises you, tell us; the App is in free beta and the behaviour is still being shaped by the people using it.