[BUG] Built-in LSP client hangs forever on servers using dynamic capability registration — please reconsider "not planned"

Resolved 💬 4 comments Opened Apr 24, 2026 by mtschoen-unity Closed May 30, 2026

This is a re-file of #32595, which was closed as "not planned." Respectfully, the underlying bug breaks the default behavior of first-party LSP plugins shipped through claude-plugins-official (csharp-lsp, elixir-lsp, and others). Closing it as "won't fix" effectively ships those plugins broken out of the box.

The bug

When an LSP server sends a client/registerCapability request (server → client, with an id) during initialization, the LSP spec requires the client to reply with:

{"jsonrpc": "2.0", "id": <id>, "result": null}

Claude Code's LSP client never sends this response. Servers that use dynamic capability registration — which includes the official csharp-ls (razzmatazz/csharp-language-server) and Elixir's Expert — block on the handshake and never finish initializing.

User-facing symptom

The LSP tool hangs indefinitely. Not a slow response, not an error — every call to hover, documentSymbol, goToDefinition, etc. on a .cs file blocks until the user gives up or kills the call. Across multiple attempts in a session, every single call hangs the same way. There is no diagnostic, no timeout message, no indication that the server is stuck mid-handshake. The plugin appears installed and "ready" but is functionally inert.

Reproduction (csharp-lsp, on a real C# project)

  1. Install csharp-lsp@claude-plugins-official v1.0.0 + csharp-ls 0.20.x.
  2. Open any .cs file in a project with a valid .sln / .csproj.
  3. Invoke any per-file LSP operation (hover, documentSymbol, goToDefinition).
  4. The call never returns.

Prior history

  • #32595 — canonical, closed "not planned" (Elixir Expert)
  • #44113 — closed as duplicate of #32595 (csharp-ls, Windows)
  • #16360 — still open, csharp-ls — missing workspace/configuration and other handlers
  • #38683 — open feature request to improve LSP compatibility for C#/.NET servers

Why this should be reopened

  1. It breaks first-party plugins. csharp-lsp ships from anthropics/claude-plugins-official. Users install it expecting it to work; it doesn't.
  2. The failure mode is the worst possible one. A silent indefinite hang is harder to diagnose than an error — there's nothing in the tool output, nothing in the plugin status, nothing pointing at the handshake. Users assume the LSP is "still indexing" or that their file is wrong.
  3. It's a small fix at the right layer. Replying {"result": null} to client/registerCapability is a couple of lines in the JSON-RPC dispatch. It does not require implementing dynamic capability handling — just acknowledging the request is enough for csharp-ls and Expert to proceed.

Environment

  • Claude Code: latest (via plugin marketplace, fetched 2026-04)
  • Plugin: csharp-lsp@claude-plugins-official v1.0.0
  • LSP server: csharp-ls 0.20.x
  • OS: macOS (Darwin 25.4.0)
  • .NET SDK: 9.x

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗