LSP tool: goToDefinition/findReferences/workspaceSymbol always return empty while hover/documentSymbol work

Status Open

Reported on v2.1.195

Maintainer reply ✓ Yes — bcherny

Activity 3 comments · opened Jun 29, 2026

💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Summary

The LSP tool's location-returning operations — goToDefinition, findReferences, workspaceSymbol — return "No definition/references/symbols found" in every case, including trivial same-file lookups. hover and documentSymbol work correctly against the same servers, so the language servers are running and resolving symbols; the failure appears to be in how the tool surfaces Location / LocationLink[] responses.

Environment

Claude Code 2.1.195 (native installer, ~/.local/share/claude/versions/)
Linux
Reproduced with pyright (Python), rust-analyzer (Rust), and clangd (C++)

Decisive repro (language-agnostic)

Open a file with a function defined and called in the same file.
hover on the call site → returns the correct type/signature, e.g.:

``(function) def _get_config() -> JiraConfig``

goToDefinition at the identical line/character → No definition found.

Same params, same position: hover succeeds where goToDefinition fails. Because the definition and use are in the same file, this rules out workspace-root / rootUri / cross-file URI resolution as the cause — the server has the symbol resolved (hover proves it), but the location is not surfaced.

findReferences behaves the same way: invoked on a function that is called many times in the project, it returns No references found.

Expected vs actual

Expected: goToDefinition returns the definition location; findReferences returns usages; workspaceSymbol returns matches.
Actual: all three return empty, across pyright, rust-analyzer, and clangd.

Scope

Broken: goToDefinition, findReferences, workspaceSymbol (very likely goToImplementation and the call-hierarchy ops too — untested).
Working: hover (Python confirmed), documentSymbol (all languages).

The tools-reference docs list all of these as supported LSP operations, so this looks like a regression/bug rather than intended behavior.

Likely cause

The tool seems to receive the server's Location / LocationLink[] response but does not map the file:// URI back to a workspace path, so a valid response is rendered as "not found." hover (a Hover response) and documentSymbol (a DocumentSymbol[] response) use different response shapes and are unaffected.

View original on GitHub ↗

3 Comments

sean-abbott · 27 days ago

Re-tested this today against all four language servers this workspace uses (Claude Code CLI, native installer). Confirms the bug is fully language-agnostic, including TypeScript which wasn't in the original repro:

pyright (Python): goToDefinition/findReferences on a same-file def/call-site pair both return empty, hover at the identical position resolves correctly.
tsgo (TypeScript): identical result. Same-file function defined and called (base64DecodeToString in a .ts file), hover on the call site resolves the signature/JSDoc correctly, goToDefinition/findReferences at the same line/character both return empty.
rust-analyzer / clangd: not re-tested this session (currently disabled in our config), but per the original report these showed the same failure.

Confirms the working theory here: this isn't tied to a particular server's response shape, since pyright and tsgo are different language servers with different implementations and both fail identically at the same op. Still reproduces on a version bumped since the original report (nothing to add on version specifics, just wanted to widen the confirmed-language set).

tuturiffic · 26 days ago

I have been dealing with this exact problem, and it took me a few hours to realize what was going on. I've also confirmed this behaviour with intelephense (PHP) and gopls (Go).

bcherny collaborator · 14 days ago

Confirmed — reproduced on 2.1.233 (Linux, pyright), and this is a regression since 2.1.47, but it only occurs under a specific condition.

In a plain project, goToDefinition/findReferences/workspaceSymbol all work correctly on 2.1.233. They return empty exactly when the file you're querying is matched by a .gitignore — including one from a git repo in a parent directory (a dotfiles repo in your home directory with a broad ignore pattern is a common cause). Since 2.1.47, the LSP tool intentionally filters results located in gitignored files (to keep node_modules/, venv/, etc. out of results), but it wrongly filters everything, including the same-file definition you asked about, and then reports "No definition found" instead of saying results were filtered. hover and documentSymbol don't go through that filter, which is why they keep working — matching your repro exactly.

You can confirm on your machine with git check-ignore -v <your file> from the project directory — it will likely print the ignore rule responsible.

We'll fix this so results in the queried file (and your own project files) aren't silently dropped, and so filtered results are reported as filtered rather than "not found".

🤖 Generated with Claude Code