What File-Level Hits Hide in Bug Localization: Paths, Functions, and Repair

Bug localization narrows an issue report to code that needs inspection or repair. File recall measures whether the right file is found, but does not distinguish useful path cues from code evidence or establish that the edit site has been located. Controlled experiments with CodeGRIP reveal both gaps. Changing displayed paths while holding reports, code previews and candidate pools fixed, we find that readable names from unrelated repositories can be more disruptive than opaque identifiers even when code remains visible. On issue-held-out SWE-bench Lite, this PathAlias intervention lowers Recall@1 by 21.8 percentage points for a code-in-prompt Qwen2.5-14B recipe without path augmentation and 4.9 points with it. Separate matched code-preview controls reveal sharply different opaque-path performance behind similar original-path scores. On GREPO, following file predictions through function selection, about one quarter of file-hit records across four rerankers also yield a changed-function hit under their own scorers. Under either tested shared scorer, neither code-visible reranker has a reliable advantage over path-only on common file wins. In separate Lite repair populations, correct supplied functions are associated with higher resolution among non-empty patches, whereas file-given comparisons remain inconclusive. File recall therefore needs to be read alongside path interventions and function outcomes, with repair interpreted under the location supplied to the fixer.