csharp-lsp: LSP tool does not respond to client/registerCapability, blocking all subsequent requests

Summary

The csharp-lsp plugin (v1.0.0) is non-functional because Claude Code's LSP infrastructure does not respond to client/registerCapability requests sent by csharp-ls during initialization. This causes the language server to block, making all subsequent LSP requests (hover, documentSymbol, findReferences, etc.) return empty results.

Environment

• Claude Code: latest
• Plugin: csharp-lsp v1.0.0
• csharp-ls: 0.20.0 (installed via dotnet tool install -g csharp-ls)
• .NET SDK: 9.0.312
• OS: Windows 11

Steps to Reproduce

1. Install the csharp-lsp plugin and csharp-ls global tool:

``
dotnet tool install -g csharp-ls --version 0.20.0
``

1. Open any .cs file in a project and use any LSP operation (hover, documentSymbol, findReferences, etc.)
2. All operations return empty / no-result responses

Root Cause

During LSP initialization, csharp-ls sends a client/registerCapability request (server→client direction, with an id field) after the initialized notification. Per the LSP specification, the client must respond to this request with:

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

Claude Code's LSP tool infrastructure does not send this response. As a result, csharp-ls blocks waiting and never processes textDocument/didOpen or any subsequent requests.

Verification

Tested with a minimal Python LSP client against csharp-ls:

• Without responding to client/registerCapability (current Claude Code behavior):

All operations (hover, documentSymbol, etc.) return empty results

• With responding to client/registerCapability:

Hover works correctly and returns type information

Expected Behavior

Claude Code's LSP client should respond to all server→client requests during the initialization handshake, including client/registerCapability.

Additional Notes

This likely affects any LSP server that sends client/registerCapability during initialization, not just csharp-ls.