[BUG] LSP workspaceSymbol operation sends empty query parameter

See full technical analysis and wrapper mitigations: https://github.com/SShadowS/claude-code-lsps/blob/main/KnownIssues.md

it says "platform:windows" but this is also happening on mac obvs

Still reproduces on 2.1.50

Still reproduces on 2.1.50

+1

+1

Still reproduces on 2.1.56 (using jdtls-lsp)

+1

+1

+1

still reproduces on v2.1.71

+1...

+1

Keep it alive dudes, damn decepticons keep closing issues after 1 week here.

This effectively renders LSP semi-useless. +1

Can confirm. The basically prevents LSP from being useful at reducing context usage.

👍

Still reproducing on v2.1.87

+1

+1

still reproducing in v2.1.97

+1

Still reproduces on 2.1.101 (pyright-lsp 1.0.0, pyright 1.1.408).

Still reproduces on 2.1.114. Here's the exact code path, for whoever picks this up:

In the Bun-compiled binary, function L81 builds the LSP request per operation. Every operation except workspaceSymbol derives textDocument + position from the tool's filePath / line / character inputs. workspaceSymbol is hardcoded:

case "workspaceSymbol":
  return { method: "workspace/symbol", params: { query: "" } };

The same file already defines pA7(filePath, line, character) — a synchronous reader that returns the identifier at the cursor. It's used for the tool's display rendering (the symbol: "X" label in the tool card), but not wired into the protocol call. Minimal fix:

case "workspaceSymbol": {
  const word = pA7(H.filePath, H.line - 1, H.character - 1) ?? "";
  return { method: "workspace/symbol", params: { query: word } };
}

Verified via a standalone LSP client against ty 0.0.31: workspace/symbol with query: "Embedder" returns 8 matches; query: "" returns null (matches the observed behavior). The bug is entirely on Claude Code's side.

still on 2.1.123 + Ubuntu

Same here, Kubuntu + Claude Code 2.1.132

Still reproducing on v2.1.132 — jdtls (Java)

Environment:

• Claude Code: 2.1.132
• Plugin: jdtls-lsp@1.0.0
• OS: Linux (Ubuntu 24.04)
• LSP server: Eclipse JDT.LS (via redhat.java VS Code extension)

Observed behavior:

documentSymbol (per-file) works correctly and returns all class/method/field symbols. workspaceSymbol always returns empty — confirmed via the LSP server logs that it receives {"query": ""}.

Impact:

The main value of workspaceSymbol over documentSymbol is cross-file symbol lookup without having to read whole files into context. With the empty query bug, every workspace-wide symbol search falls back to grep or reading multiple files manually — which defeats the token-saving purpose of having an
LSP tool in the first place.

Workaround in use: Bash + grep -rn on src/main/java.

The root cause analysis by @vrppaul (hardcoded query: "" in the workspaceSymbol case of the request builder) matches exactly what I observe. The proposed one-liner fix looks correct.

This is not fixed for workspaceSymbol using jdtls on windows, all other LSP tools work in jdtls using Claude Code v2.1.138 except workspaceSymbol.

Still present in v2.1.146 (native binary), and confirmed 100% client-side — the language server is fine.

Two additions to this thread: confirmation it's unfixed in the current native build, plus an empirical test that I think settles whether passing a real query is sufficient.

1) Still hardcoded in the latest build. In the native claude.exe v2.1.146, the LSP request builder still emits a literal empty query for this one operation:

case "workspaceSymbol": return { method: "workspace/symbol", params: { query: "" } };

Every other operation derives { textDocument: { uri }, position } from the line/character args; workspaceSymbol alone sends neither — the line/character inputs are silently discarded.

2) The server side is provably fine — the empty query is the _sole_ cause. I drove the same Roslyn server (Microsoft.CodeAnalysis.LanguageServer), launched exactly as Claude Code launches it, and sent workspace/symbol directly after waiting for projectInitializationComplete:

| query sent | results |
|---|---|
| "DistanceCalculator" | 18 |
| "RecognizeAsync" | 6 |
| "IOcrProvider" | 1 |
| "" (what Claude Code sends) | 0 |

Rich results for a real query, nothing for the empty string — matching the gopls example in #30948. No indexing/warm-up factor was involved: the project was fully loaded (every other operation worked at the same moment).

3) Minimal fix. The client already extracts the identifier at line/character (it's used to build the display label for goToDefinition/hover); routing that token into the workspace/symbol params — or adding an optional query field to the LSP tool schema, as proposed in #30948 — is sufficient.

Environment: Windows 11, C# via Microsoft.CodeAnalysis.LanguageServer, Claude Code native binary v2.1.146.

Should be solve in the latest version, havn't tested it yet. You?

Should be solve in the latest version, havn't tested it yet. You?

just tested it -- it now works!

Confirmed fixed on 2.1.162 (Windows). workspaceSymbol now takes a query and passes it through; real queries return matches. Good to close.