[BUG] C# LSP (csharp-ls) not working - missing workspace/configuration and other request handlers

[paulditerwich]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

The built-in LSP support doesn't work with csharp-ls (C# language server). The LSP client is missing handlers for several standard LSP requests that csharp-ls requires during initialization:

1. workspace/configuration - Server requests configuration settings (specifically the solution path)
2. client/registerCapability - Server dynamically registers capabilities
3. window/workDoneProgress/create - Server creates progress tokens for indexing feedback

Additionally, the workspace configuration capability is disabled (configuration:!1 in cli.js).

Without these, the server fails to initialize properly and returns empty results for operations like documentSymbol, hover, etc.

What Should Happen?

The LSP client should handle these standard LSP protocol requests so that csharp-ls (and other language servers that use these features) work out of the box.

After manually patching cli.js to add these handlers, all LSP operations work correctly (documentSymbol, hover, goToDefinition, findReferences).

Error Messages/Logs

Steps to Reproduce

1. Configure csharp-ls plugin in ~/.claude/plugins/csharp-lsp/config.json
2. Open a C# project with a .sln file
3. Try any LSP operation on a .cs file, e.g.: LSP documentSymbol
4. Operation returns empty results or fails

Debug logs show:

• Server sends workspace/configuration request → no handler
• Server sends client/registerCapability request → no handler
• Server sends window/workDoneProgress/create request → no handler

Claude Model

None

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.0.76

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Note: This issue persists even after applying the LSP initialize() fix from:
https://gist.github.com/Zamua/f7ca58ce5dd9ba61279ea195a01b190c

That fix addresses the empty initialize() function (issue #13952), but csharp-ls
still fails because it requires these additional LSP protocol handlers that the
client doesn't implement:

1. workspace/configuration - needs to return solution path
2. client/registerCapability - dynamic capability registration
3. window/workDoneProgress/create - progress token creation

The gist fix enables LSP servers to load, but csharp-ls specifically needs these
request handlers to function. Other LSP servers (like typescript-lsp) may work
without them, but csharp-ls requires all three during initialization.

Workaround: Patch cli.js to:

1. Enable capabilities.workspace.configuration: true
2. Add handlers:

B.onRequest("workspace/configuration", (P) => {
  return P.items.map((b) => {
    if (b.section === "csharp") return { solution: "path/to/Solution.sln" };
    return {};
  });
});
B.onRequest("client/registerCapability", () => null);
B.onRequest("window/workDoneProgress/create", () => null);

Suggested fix: The LSP plugin config already has a solution field - this could be read by the workspace/configuration handler instead of requiring manual patching.

csharp-ls version: 0.19.0

[b-straub]

So this means that even with the fixes from 2.1.1 the csharp-lsp is still broken and not functional, correct?

[paulditerwich]

@b-straub Yes, still broken in 2.1.1 — confirmed 2026-01-08.

I have a working patch.

---

Root Cause

Claude Code's LSP client needs three handlers that csharp-ls requires:

Missing Handler	Purpose
workspace/configuration	Provide .sln path
client/registerCapability	Dynamic capability registration
window/workDoneProgress/create	Progress tokens

And capabilities.workspace.configuration is disabled.

---

The Fix

File: ~/.claude/local/node_modules/@anthropic-ai/claude-code/cli.js

1. Enable configuration capability:

sed -i '' 's/configuration:!1/configuration:!0/g' cli.js

2. Inject these handlers (before the LSP client started log):
L.onRequest("workspace/configuration", (P) => {
  return P.items.map((b) => {
    if (b.section === "csharp") {
      try {
        const sln = require("fs")
          .readdirSync(process.cwd())
          .find(f => f.endsWith(".sln"));
        if (sln) return { solution: sln };
      } catch (e) {}
    }
    return {};
  });
});

L.onRequest("client/registerCapability", () => null);
L.onRequest("window/workDoneProgress/create", () => null);

sed -i '' 's/W\.length=0,v(`LSP client started for \${A}`)/W.length=0,L.onRequest("workspace\/configuration",(P)=>{return P.items.map((b)=>{if(b.section==="csharp"){try{const sln=require("fs").readdirSync(process.cwd()).find(f=>f.endsWith(".sln"));if(sln)return{solution:sln}}catch(e){}}return{}})}),L.onRequest("client\/registerCapability",()=>null),L.onRequest("window\/workDoneProgress\/create",()=>null),v(`LSP client started for ${A}`)/' cli.js

Variable names change per version. Find yours:
grep -oE '[A-Z]\.onRequest\("' cli.js | sort | uniq -c
grep -oE '.{20}LSP client started for' cli.js
---
Test Results (after restart)
┌────────────────────┬────────────┬─────┐
│     Operation      │ TypeScript │ C#  │
├────────────────────┼────────────┼─────┤
│ hover              │     ✅     │ ✅  │
├────────────────────┼────────────┼─────┤
│ goToDefinition     │     ✅     │ ✅  │
├────────────────────┼────────────┼─────┤
│ documentSymbol     │     ✅     │ ✅  │
├────────────────────┼────────────┼─────┤
│ goToImplementation │     —      │ ✅  │
├────────────────────┼────────────┼─────┤
│ findReferences     │     —      │ ✅  │
└────────────────────┴────────────┴─────┘
---

Suggested Official Fix

The solution field already exists in the plugin config schema. The LSP client just needs to:

1. Enable workspace.configuration capability
2. Return config.solution when workspace/configuration is requested for csharp
3. Handle client/registerCapability and window/workDoneProgress/create

[icanhasjonas]

Alternative workaround: Bun adapter (no cli.js patching)

I hit the same issue and built a different workaround - a transparent proxy that intercepts the problematic requests before they reach Claude Code.

How it works

Instead of patching cli.js, rename the original csharp-ls binary and replace it with a Bun script that:

1. Spawns the real csharp-ls
2. Proxies all LSP messages between Claude Code and csharp-ls
3. Intercepts these three methods and responds with null directly to csharp-ls:
   • window/workDoneProgress/create
   • window/workDoneProgress/cancel
   • client/registerCapability
4. Passes everything else through (including workspace/configuration which Claude Code handles fine)

Why this approach?

• Survives updates - cli.js gets replaced on update, the adapter doesn't
• Non-invasive - doesn't touch Claude Code internals
• Easy to remove - just swap the binaries back when this is fixed upstream
• Debuggable - set LSP_ADAPTER_DEBUG=1 to see all LSP traffic

Setup

# Rename original
mv ~/.dotnet/tools/csharp-ls ~/.dotnet/tools/csharp-ls-original

# Create adapter (save the Bun script as ~/.dotnet/tools/csharp-ls)
chmod +x ~/.dotnet/tools/csharp-ls

Full adapter code (~150 lines of Bun/TypeScript): https://gist.github.com/icanhasjonas/4c04328b8c886277399ad23f41549571

Works great here - all LSP operations (documentSymbol, hover, goToDefinition, findReferences, etc.) now work perfectly.

[MagnificentS]

@b-straub Yes, still broken in 2.1.1 — confirmed 2026-01-08.

I have a working patch.

Root Cause

Claude Code's LSP client needs three handlers that csharp-ls requires:

Missing Handler Purpose
workspace/configuration Provide .sln path
client/registerCapability Dynamic capability registration
window/workDoneProgress/create Progress tokens
And capabilities.workspace.configuration is disabled.

The Fix

File: ~/.claude/local/node_modules/@anthropic-ai/claude-code/cli.js

1. Enable configuration capability:

sed -i '' 's/configuration:!1/configuration:!0/g' cli.js

2. Inject these handlers (before the LSP client started log):
   L.onRequest("workspace/configuration", (P) => {
   return P.items.map((b) => {
   if (b.section === "csharp") {
   try {
   const sln = require("fs")
   .readdirSync(process.cwd())
   .find(f => f.endsWith(".sln"));
   if (sln) return { solution: sln };
   } catch (e) {}
   }
   return {};
   });
   });

L.onRequest("client/registerCapability", () => null);
L.onRequest("window/workDoneProgress/create", () => null);

sed -i '' 's/W.length=0,v(LSP client started for \${A})/W.length=0,L.onRequest("workspace/configuration",(P)=>{return P.items.map((b)=>{if(b.section==="csharp"){try{const sln=require("fs").readdirSync(process.cwd()).find(f=>f.endsWith(".sln"));if(sln)return{solution:sln}}catch(e){}}return{}})}),L.onRequest("client/registerCapability",()=>null),L.onRequest("window/workDoneProgress/create",()=>null),v(LSP client started for ${A})/' cli.js

Variable names change per version. Find yours:
grep -oE '[A-Z].onRequest("' cli.js | sort | uniq -c
grep -oE '.{20}LSP client started for' cli.js

Test Results (after restart)
┌────────────────────┬────────────┬─────┐
│ Operation │ TypeScript │ C# │
├────────────────────┼────────────┼─────┤
│ hover │ ✅ │ ✅ │
├────────────────────┼────────────┼─────┤
│ goToDefinition │ ✅ │ ✅ │
├────────────────────┼────────────┼─────┤
│ documentSymbol │ ✅ │ ✅ │
├────────────────────┼────────────┼─────┤
│ goToImplementation │ — │ ✅ │
├────────────────────┼────────────┼─────┤
│ findReferences │ — │ ✅ │
└────────────────────┴────────────┴─────┘

Suggested Official Fix

The solution field already exists in the plugin config schema. The LSP client just needs to:

1. Enable workspace.configuration capability
2. Return config.solution when workspace/configuration is requested for csharp
3. Handle client/registerCapability and window/workDoneProgress/create

Could you kindly share your file please?

[b-straub]

I did install the BUN adapter, but I have no idea how it's supposed to work. The plugin is just a ReadME csharp-lsp and Claud complains that no fitting MCP is present.

CC: I see csharp-lsp@claude-plugins-official is enabled in your settings, but it's not showing as connected in the MCP server list.

[paulditerwich]

@MagnificentS Here's the patch script: https://gist.github.com/paulditerwich/ccadc92f026f6c1bce9fbe4f8720c3f8

curl -fsSL https://gist.githubusercontent.com/paulditerwich/ccadc92f026f6c1bce9fbe4f8720c3f8/raw/csharp-lsp-fix.sh | bash

Creates a backup automatically. Restore with --restore flag.

[icanhasjonas]

@MagnificentS Here's the patch script: gist.github.com/paulditerwich/ccadc92f026f6c1bce9fbe4f8720c3f8

curl -fsSL https://gist.githubusercontent.com/paulditerwich/ccadc92f026f6c1bce9fbe4f8720c3f8/raw/csharp-lsp-fix.sh | bash

Creates a backup automatically. Restore with --restore flag.

Setting Up C# LSP in Claude Code (Complete Guide)

A step-by-step guide to get C# code intelligence working in Claude Code.

Prerequisites

• Bun installed (curl -fsSL https://bun.sh/install | bash)
• .NET SDK installed
• Claude Code installed

Step 1: Install csharp-ls

dotnet tool install --global csharp-ls

Verify it's installed:

~/.dotnet/tools/csharp-ls --version
# Should output: csharp-ls version 0.21.0.0 (or similar)

Step 2: Install the LSP Adapter

Claude Code has a bug where it doesn't handle certain LSP requests, causing csharp-ls to crash. We fix this with a transparent adapter.

2a. Rename the original binary

mv ~/.dotnet/tools/csharp-ls ~/.dotnet/tools/csharp-ls-original

2b. Create the adapter

curl -fsSL https://gist.githubusercontent.com/icanhasjonas/4c04328b8c886277399ad23f41549571/raw/csharp-ls \
  -o ~/.dotnet/tools/csharp-ls

chmod +x ~/.dotnet/tools/csharp-ls

2c. Verify the adapter works

echo "" | LSP_ADAPTER_DEBUG=1 ~/.dotnet/tools/csharp-ls 2>&1 | head -3
# Should output:
# [ADAPTER] Starting csharp-ls adapter...
# [ADAPTER] Spawned csharp-ls, pid: XXXXX

Step 3: Enable the LSP Plugin in Claude Code

Edit ~/.claude/settings.json and add/update the enabledPlugins section:

{
  "enabledPlugins": {
    "csharp-lsp@claude-plugins-official": true
  }
}

Full example ~/.claude/settings.json:

{
  "theme": "dark",
  "enabledPlugins": {
    "csharp-lsp@claude-plugins-official": true,
    "typescript-lsp@claude-plugins-official": true,
    "pyright-lsp@claude-plugins-official": true
  }
}

Step 4: Restart Claude Code

Exit and restart Claude Code for the plugin to load.

Step 5: Test It!

In a C# project, ask Claude to use LSP:

Use LSP documentSymbol on src/MyController.cs

Or Claude will automatically use LSP for code navigation tasks like:

• "Find where IMyService is defined"
• "What methods are in this class?"
• "Find all references to this method"

Troubleshooting

Enable debug logging

LSP_ADAPTER_DEBUG=1 claude

Check logs at ~/.claude/debug/ for [ADAPTER] entries.

"No LSP server available"

1. Check the plugin is enabled: cat ~/.claude/settings.json | grep csharp
2. Restart Claude Code
3. Check debug logs for errors

Verify adapter is being used

grep -i "ADAPTER" ~/.claude/debug/*.txt | tail -10

You should see [ADAPTER] Starting csharp-ls adapter...

What the Adapter Does

The adapter intercepts three LSP methods that Claude Code doesn't handle properly:

Method	Issue
window/workDoneProgress/create	Claude Code doesn't implement handler
window/workDoneProgress/cancel	Claude Code doesn't implement handler
client/registerCapability	Claude Code sends invalid response

Everything else passes through normally.

Project-Specific Settings (Optional)

For project-specific LSP settings, create .claude/settings.local.json in your project:

{
  "permissions": {
    "allow": [
      "Read(**)"
    ]
  }
}

Available LSP Operations

Once set up, Claude can use these operations:

Operation	What it does
documentSymbol	List all classes, methods, fields in a file
hover	Get type info and documentation
goToDefinition	Jump to where something is defined
findReferences	Find all usages of a symbol
goToImplementation	Find interface implementations
workspaceSymbol	Search for symbols across the codebase

References

• GitHub Issue #16360 - The bug this fixes
• Adapter Gist - Full adapter source code

[b-straub]

There are some problems

1. your bun code has a hardcoded path const csharpLs = spawn(["/Users/xxxx/.dotnet/tools/csharp-ls-original"], {
2. dotnet tool install --global csharp-language-server likely you mean "dotnet tool install --global csharp-ls"
3. the tool is not installed in "tools" but in "toolResolverCache" .NET 10 MacOS

I changed the code to
const csharpLs = spawn(["dotnet", "csharp-ls"], { stdin: "pipe", stdout: "pipe", stderr: "inherit", });

And Claude debug now showing various log entries for LSP SERVER and LSP PROTOCOL
Last entry: [LSP SERVER plugin:csharp-lsp:csharp-ls] 13:52:58.409 info: Roslyn.Solution[0]
Will use MSBuild props: map [(TargetFramework, net10.0)]

When asking in Rider IDE CC something like:

LSP workspaceSymbol IMyInterface

⏺ The IDE MCP server doesn't provide workspaceSymbol functionality - only getDiagnostics is available.

[icanhasjonas]

@b-straub .. oups! missed the hard coded path ;-)

Your change is perfect! Nice catch.
I updated the original comment above..

[b-straub]

I still don't have the faintest idea how this is supposed to work, whatever I try in Rider or VS Code CC mentions always that no LSP MCP is installed. For me there is something fundamentally broken with the plugin approach. This should be straightforward to install and use.

[dselivanov]

Anthropic wiped out LSP in 2.1.0+ from system prompt

marckrenn/claude-code-changelog@v2.0.76...v2.1.1#diff-b0a16d13c25d701124251a8943c92de0ff67deacae73de1e83107722f5e5d7f1L741