Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Built-in LSP client hangs forever on servers using dynamic capability registration — please reconsider "not planned" [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#52693•Fetched 2026-04-24 10:42:14
View on GitHub
Comments
2
Participants
2
Timeline
7
Reactions
0
Author
mtschoen-unitymtschoen-unity
Participants
github-actions[bot]github-actions[bot]mtschoen-unitymtschoen-unity
Timeline (top)
labeled ×5commented ×2

Error Message

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. 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.

Fix Action

Fix / Workaround

  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.

Code Example

{"jsonrpc": "2.0", "id": <id>, "result": null}
RAW_BUFFERClick to expand / collapse

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

extent analysis

TL;DR

The LSP client in Claude Code should be updated to respond with {"jsonrpc": "2.0", "id": <id>, "result": null} to client/registerCapability requests to fix the handshake issue with certain LSP servers.

Guidance

  • Verify that the LSP client is not sending the required response to client/registerCapability requests by checking the network traffic or logs.
  • Implement a fix in the LSP client to send the required response, which should be a simple addition to the JSON-RPC dispatch logic.
  • Test the fix with the csharp-lsp plugin and csharp-ls server to ensure that the handshake completes successfully and LSP operations work as expected.
  • Consider adding logging or diagnostic messages to help users identify issues with the LSP handshake in the future.

Example

// Example response to client/registerCapability request
{
  "jsonrpc": "2.0",
  "id": "<id>",
  "result": null
}

Notes

The fix should be applied to the Claude Code LSP client, and it's a relatively small change that doesn't require implementing dynamic capability handling.

Recommendation

Apply workaround: update the LSP client to respond to client/registerCapability requests, as this is a critical fix for first-party plugins like csharp-lsp and will improve the overall user experience.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#API rate limit#retriever error#indexing error#inference speed#output truncation

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Built-in LSP client hangs forever on servers using dynamic capability registration — please reconsider "not planned" [2 comments, 2 participants]