LSP tool returns empty results despite server responding correctly (Windows)

Bug Description

LSP tool operations (hover, documentSymbol, goToDefinition, findReferences) always return "No results" messages, even though the language server (Pyright) responds with valid data. Diagnostics (passive publishDiagnostics notifications) work correctly.

Environment

• Claude Code version: 2.1.72
• OS: Windows 11
• LSP server: Pyright 1.1.408 (via node langserver.index.js --stdio)
• Plugin sources tested: Official (claude-plugins-official), community (boostvolt/claude-code-lsps), and local custom plugin — all exhibit the same behavior

Steps to Reproduce

1. Install any pyright LSP plugin (official or third-party)
2. Set ENABLE_LSP_TOOL=1 in ~/.claude/settings.json env
3. Restart Claude Code
4. Open a Python project
5. Use the LSP tool: hover, documentSymbol, or goToDefinition on any Python file

Expected Behavior

LSP tool should return the hover info, symbols, or definition location from Pyright's response.

Actual Behavior

All LSP tool operations return generic "No results" messages:

• hover → "No hover information available"
• documentSymbol → "No symbols found in document"
• goToDefinition → "No definition found"

Debug Log Evidence

Debug logs confirm the LSP protocol communication is working correctly:

[LSP PROTOCOL plugin:pyright:python] Sending request 'textDocument/hover - (3)'
[LSP PROTOCOL plugin:pyright:python] Received response 'textDocument/hover - (3)' in 57ms.

[LSP PROTOCOL plugin:pyright:python] Sending request 'textDocument/documentSymbol - (2)'
[LSP PROTOCOL plugin:pyright:python] Received response 'textDocument/documentSymbol - (2)' in 37ms.

Responses arrive in 37-353ms, but Claude Code displays "No results" to the user.

Manual Verification

I wrote a Node.js script to manually spawn pyright-langserver and send the same LSP requests. Pyright returns correct results:

hover → (function) def hello(name: str) -> str
documentSymbol → Found hello, MY_PATH, result symbols with correct ranges
goToDefinition → Correctly resolves Path to pathlib/__init__.pyi

This proves Pyright is working correctly and the bug is in Claude Code's LSP response parsing/handling layer.

Additional Notes

• Diagnostics work: Passive textDocument/publishDiagnostics notifications are correctly received and displayed (e.g., "Import could not be resolved", unused variable warnings)
• Multiple plugin formats tested: Tried lspServers inline in marketplace.json, standalone .lsp.json, and plugin.json — all three code paths produce the same behavior
• Windows-specific spawn issue: On Windows, pyright-langserver (a bash shim) cannot be spawned by uv_spawn. Workaround: use node with the full path to langserver.index.js. This resolves the spawn issue but the response parsing bug remains.
• Total LSP servers loaded: Was initially 0 until ENABLE_LSP_TOOL=1 was set, then correctly shows loaded servers.