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

Open 💬 0 comments Opened Jun 29, 2026 by sean-abbott

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)

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

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

  1. goToDefinition at the identical line/characterNo 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 ↗