[FEATURE] Transparency/debug view for what @-mention retrieval actually pulled into context

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 19, 2026

Summary

When a user @-mentions a file/symbol (or Claude auto-retrieves related context), there's no debug/transparency view showing exactly what got pulled into context as a result — what matched, what didn't, and why. Please add a way to inspect @-mention/context-retrieval results directly.

Current behavior

@-mentioning a file or symbol resolves to some set of retrieved content that gets folded into context, but the user has no visibility into the actual retrieval step itself — whether it matched exactly what was intended, whether related files were pulled in alongside it, or why a particular match was chosen over another when the mention was ambiguous (e.g. a common filename that exists in multiple directories).

Motivation

Comparison articles across the AI-coding-tool market (codeant.ai and related 2026 pieces comparing Cursor, Windsurf, and GitHub Copilot) repeatedly cite Cursor's @-mention/codebase-retrieval UX as best-in-class, specifically because of how legible and controllable it is — implying retrieval transparency itself is a meaningfully differentiating capability, not just retrieval accuracy. Without a way to see what actually got retrieved, users can't tell whether an unexpected response is due to a retrieval miss (wrong file pulled in) versus a reasoning miss (right context, wrong conclusion) — which matters for knowing what to fix.

Proposed behavior

  1. A lightweight, on-request view (e.g. expandable in the transcript, or a debug command) showing exactly what an @-mention or auto-retrieval step resolved to — which file(s)/symbol(s), and why, when the mention was ambiguous.
  2. Surface near-miss candidates when an ambiguous mention resolved to one option among several plausible matches, so the user can tell if the wrong one was picked.
  3. Should be opt-in/on-demand rather than always-visible clutter — most retrievals are unambiguous and don't need inspection.

Why it matters

  • Turns "why didn't Claude use the file I meant" from a guessing game into a direct answer.
  • Addresses a capability the market treats as a real differentiator (retrieval transparency), not a purely cosmetic one.

Related issues (adjacent, not duplicates)

  • #21151 [FEATURE] No indication of WHICH file for READ tool — adjacent (visibility into which file a tool touched), but scoped to the Read tool's own execution rather than @-mention/context-retrieval resolution specifically; a shared "show me what actually got used" theme, different mechanism.

Notes

  • Reviewed for duplicates before filing (multiple search passes: "at-mention file retrieval quality debug context pulled in", "show what files were included context window transparency", "explain why this file was retrieved into context") — nothing found describing @-mention retrieval transparency specifically, as of 2026-07-19.
  • Sourced from market research: codeant.ai and related 2026 comparison pieces citing Cursor's retrieval UX as a named best-in-class differentiator.

View original on GitHub ↗