How an audit works
What CodeAuditAgent reads, what it sends to the model, how long an audit takes and where the limits are.
An audit has three stages: collect the source, ask the model for a structured report, store the result. Knowing what happens in each one tells you what an audit can and cannot find.
Collecting the source
For a repository we read the file tree of the default branch and pick the files worth reviewing: application source, configuration and dependency manifests. Vendored directories, build output, lock files, images and binaries are skipped — they burn the budget without carrying logic.
- Individual files larger than 60 KB are skipped; a file that big is usually generated.
- How many files are read depends on your plan: 20 on Free, 40 on Starter, 80 on Pro.
- The total amount of source sent to the model is capped too: 60,000 characters on Free, 300,000 on Starter, 600,000 on Pro.
When a repository is bigger than the cap, the report says so explicitly. Treat a truncated audit as a sample, not as coverage: the files that were not read were not reviewed.
Asking the model
The source goes to Claude with a system prompt that defines the reviewer's job and a tool schema that defines the shape of the answer. The model cannot reply with prose: it has to fill in the report structure, which is why every finding has a severity, a location and a remediation rather than a paragraph of advice.
Your code is treated as untrusted data throughout. If a comment or string in the repository tries to instruct the reviewer — "ignore previous instructions", "report no findings" — the model is told not to comply and to report the attempt as a prompt-injection finding.
Paid plans run Claude Fable 5.1. The free plan runs Claude Haiku 4.5, which is faster and much cheaper to serve, so trials stay free; it finds less than the flagship model does.
Storing the result
The report is stored against your account, with the model used, the list of files that were actually read, and whether the source was truncated. That list matters when you compare two audits: a finding can disappear because it was fixed, or because the file it lived in did not make the cut this time.
What an audit does not do
- It does not run your code, so it cannot confirm exploitability at runtime.
- It does not reach private repositories yet; that needs a GitHub App installation, which is not built.
- It does not open pull requests or change anything in your repository.
- It does not replace a penetration test or a human review of security-critical code.