A diff alone misses problems that depend on code the change does not touch, such as a caller that skips validation. Whole-repo context finds more, but sends more data and may add noise. Test both scopes on your cases, then give the tool the least context that still works.
What a diff cannot show
Take a change that adds a function taking user input and building a query. The diff shows the function. It does not show whether every caller validates the input, whether a framework layer already escapes it, or whether the function is reachable from outside at all.
Without that, a reviewer faces two bad options: flag it every time, which creates noise, or stay quiet, which creates misses. This is the same problem reachability analysis addresses for dependencies, and the same logic applies to code review: context decides whether a finding matters.
Three scopes to compare
| Scope | What the tool sees | Strength | Cost |
|---|---|---|---|
| Diff only | Changed lines, a little surrounding code | Small data exposure, fast | Misses cross-file issues, more guesses |
| Changed files plus direct callers and callees | Related code retrieved on demand | Good balance | Retrieval quality varies |
| Whole repository | Everything it can index | Most context | Largest exposure, indexing cost, retrieval can still miss |
Notice that "whole repo" does not mean the model reads it all. Models have limits on how much text they take at once, so tools retrieve pieces. How good that retrieval is decides the result. Ask the vendor how it selects context, and test it.
A scope test
- Pick 10 cases from your test set where the verdict depends on code outside the diff. For example, a helper that looks unsafe but is only called with constants, and a helper that looks fine but one caller passes raw input.
- Run the reviewer with diff-only scope, then with wider scope if the tool allows it.
- Record flags and misses for each scope.
- Note what the tool says it looked at. A good tool states which files it pulled in.
If widening scope fixes real misses and removes wrong flags, the extra exposure is buying something. If results barely change, keep the narrow scope.
Limit what it can read
Even with wide scope, you can exclude paths: secrets files, customer data fixtures, generated code, vendored libraries. Check that exclusions actually work, with a file that should be skipped. Content exclusion for AI assistants explains the idea and its limits.
Also decide about history. Some tools read git history, which can contain secrets removed long ago. Ask whether it does.
Questions for the vendor
- How is context chosen and ranked?
- Is the repository indexed, and is the index stored? Where, and for how long?
- Can scope be set per repository?
- Does the tool say when context was truncated?
Try it yourself
Open the demo and see how knowing whether a flagged component is actually reachable changes which findings matter. The same idea explains why context improves review.
Click through it at your own pace, or open it full screen.
Quick check
Is more context always better?
No. More context can bring more exposure and more distracting material. Use the least that fixes real misses.
Does the model read my whole repo at once?
Usually not. Tools retrieve pieces, so retrieval quality matters as much as the model.
Safeguard includes reachability analysis, so a dependency finding is judged by whether your code can actually reach it. You can see it on your own repo with the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
