C# LSP for Claude Code: pick the server, then get it working on Windows

[kyle-sexton]

Child of #3535. Highest upside of the four: C# is this fleet's primary ecosystem and it currently has no language server at all, so every C# edit Claude makes goes without diagnostics or navigation.

Current state

csharp-lsp@claude-plugins-official is installable but inert. Claude Code's LSP client returns -32601 "Unhandled method" to three server→client requests csharp-ls sends at initialization:

• client/registerCapability
• workspace/configuration
• window/workDoneProgress/create ← this one aborts solution loading

Result: the Roslyn workspace never initializes, so no symbols, hover, go-to-definition, references or diagnostics ever become available. anthropics/claude-plugins-official#1359, open since 2026-04-11. No fix in the Claude Code changelog through 2.1.252 (grepped for csharp, C#, and all three handler names: zero hits).

This is not a csharp-ls defect — it shipped 0.27.0 on 2026-08-24 and is actively maintained.

We deliberately did not add csharp-lsp to the dotfiles seed for this reason.

Open question this issue must answer first

Which C# language server? Do not assume csharp-ls just because Anthropic's plugin uses it. At minimum compare:

• csharp-ls (razzmatazz) — what the official plugin targets. Actively maintained. Known to need the three handlers above.
• Microsoft.CodeAnalysis.LanguageServer (Roslyn) — the server behind the official VS Code C# extension, published as a standalone NuGet package and consumed by non-Microsoft editors. Research its licensing terms for use outside VS Code, its handler expectations, and whether it needs fewer client capabilities than csharp-ls or more.
• Anything else current. Check what the neovim and Zed C# communities actually run in 2026, since they hit the same "LSP client that isn't VS Code" constraint we do.

The answer may make the shim unnecessary, or may make it mandatory. Decide on evidence.

Then: does a proxying shim work?

If the chosen server needs handlers Claude Code does not implement, a shim that sits between them and answers those three requests itself is the candidate fix (see #3535). The upstream issue proposes the exact responses:

• client/registerCapability → { result: null }
• workspace/configuration → { result: params.items.map(() => null) }
• window/workDoneProgress/create → { result: null }

Confirm those are sufficient — the issue reports them as a working local patch, which is evidence but not proof for a proxy sitting outside the client.

Acceptance

• A named server, with the reasoning recorded and the rejected alternatives named.
• On Windows: the LSP tool appears, and documentSymbol, hover, goToDefinition and findReferences return correct results in a real multi-project solution — not a toy one, since solution loading is exactly what fails today.
• The same on WSL/Linux, or an explicit recorded decision that Windows-only is acceptable for now.
• No cli.js patching (EPIC: make Claude Code language servers work on Windows — one broken language, not four #3535 non-goal).
• Whatever the operator must install by hand is documented in one place.

Explicitly out of scope

Making this work in Claude Code cloud sessions. Language servers do not start there.

[kyle-sexton]

Empirical result: this issue's stated premise does not reproduce on csharp-ls 0.27.0

Ran the experiment rather than inheriting the upstream diagnosis. A client that refuses the very requests #1359 blames still gets working cross-project C# intelligence. That changes what this issue should investigate.

Method

Linux x64, .NET SDK 10.0.400, csharp-ls 0.27.0 installed via dotnet tool install --global csharp-ls. A two-project solution (classic .sln, App → project-reference → Lib) driven by a hand-written LSP client over stdio in two modes:

• strict — simulates Claude Code as miro: setup skill omits the headless --config seeding path required by PLUGIN-PHILOSOPHY #1359 describes it: answers every server→client request with -32601 "Unhandled method".
• lenient — simulates the proposed proxying shim: answers client/registerCapability → null, workspace/configuration → [null, …], window/workDoneProgress/create → null.

Both modes advertised workspace.configuration: true and window.workDoneProgress: true in client capabilities, then strict refused anyway. That is deliberately harsher than a client which simply never advertises them, since a well-behaved server would not send the requests at all in that case.

Results — identical in both modes

Probe	strict (refuses)	lenient (answers)
initialize	OK	OK
textDocument/documentSymbol	OK	OK
textDocument/hover	OK	OK
cross-project definition (App/Program.cs → Lib/Class1.cs)	RESOLVED → Class1.cs:2	RESOLVED → Class1.cs:2
cross-project references	RESOLVED → Class1.cs:2, Program.cs:2	RESOLVED → Class1.cs:2, Program.cs:2
$/progress notifications	0	2

Cross-project references returning the usage in the other project is the load-bearing row. documentSymbol and hover can be answered from one file's syntax tree and prove nothing about workspace state; resolving a symbol across a project reference requires the solution graph — the exact thing #1359 says never initializes.

The only observable difference between the two modes was progress reporting. No capability was lost by refusing.

Two further corrections to the premise

1. client/registerCapability was never sent at all. csharp-ls 0.27.0 requested only workspace/configuration and window/workDoneProgress/create. The upstream issue lists three; in this configuration only two ever appear.
2. Timeline fits a stale report. miro: setup skill omits the headless --config seeding path required by PLUGIN-PHILOSOPHY #1359 was filed 2026-04-11. csharp-ls has shipped 0.24.0 (2026-04-16), 0.25.0 (2026-06-11), 0.26.0 (2026-07-15) and 0.27.0 (2026-08-24) since — the report may well have been accurate against the version current when it was written.

What this does NOT establish

Stated plainly, because the gap is the whole reason this still needs Windows time:

• Linux only. Not reproduced on Windows, which is the platform that matters here.
• Not tested through Claude Code. Claude Code does not start plugin language servers in cloud sessions, so this used a hand-written client. It proves what csharp-ls tolerates, not what Claude Code's client actually sends.
• Small solution. Two projects. A large real solution may hit timeouts or memory limits this does not exercise.
• Only csharp-ls. Says nothing about Microsoft.CodeAnalysis.LanguageServer.

A more likely Windows root cause, worth testing first

Incidental finding that may matter more than the handler question:

dotnet tool install --global csharp-ls produces a native apphost executable, not a .cmd or .bat shim. So the npm-shim spawn problem that breaks #3537 does not apply to csharp-ls — good news, and it removes one hypothesis.

But the apphost has to locate the .NET runtime at launch, and in this container it failed outright until DOTNET_ROOT was set:

You must install .NET to run this application.
.NET location: Not found
  Environment variable:
    DOTNET_ROOT_X64 = <not set>
    DOTNET_ROOT = <not set>
  Default location:
    /usr/share/dotnet

Claude Code spawns language servers without a shell, so the server inherits the environment the CLI process happens to have — not a login shell's. On a Windows box where .NET is not in the default location, or where DOTNET_ROOT is set by a shell profile rather than machine-wide, csharp-ls.exe would fail to launch exactly this way, and the symptom would be indistinguishable from "the plugin doesn't work". That also fits anthropics/claude-code#29307 ("C# LSP plugin not exposing LSP tool") better than a protocol fault does.

Revised order of work

1. On Windows, check the launch environment before anything else. Confirm csharp-ls.exe exists (where.exe csharp-ls), then confirm it runs from a non-login context, and check whether DOTNET_ROOT is set machine-wide or only in a profile.
2. Then install csharp-lsp@claude-plugins-official and see whether it actually fails on 0.27.0, rather than assuming it does. The premise may simply have expired.
3. Only if it does fail, capture what Claude Code's client actually sends and receives, and compare against the strict-mode transcript above.
4. Treat the proxying shim as a contingency, not the plan. On this evidence it would buy progress notifications and nothing else.

The server-selection question in the issue body still stands on its own merits — Microsoft.CodeAnalysis.LanguageServer may be better regardless — and separate research on that is in flight.

Scripts and the sample solution are reproducible; say the word and I will commit them under this repo so the Windows run is a matter of executing the same two commands.

---

Generated by Claude Code

[kyle-sexton]

Server selection: target csharp-ls >= 0.24.0, write no shim

Follow-up to the empirical comment above, now with the server-choice research done. Three of this issue's premises reverse.

1. The blocker is a stale-version artifact, and now has a version history

claude-plugins-official#1359 was filed against csharp-ls 0.16.0.0. The fixes shipped in 0.22.0 (2026-02-05, capability check, PR #309) and 0.24.0 (2026-04-16, error tolerance, PR #348). The source file the issue names as root cause, Handlers/Initialization.fs, 404s on main — it no longer exists.

That reconciles with my probe and with a second, independent one. Note the two probes disagreed in a way that is itself informative:

Probe	Client capabilities declared	Server→client requests csharp-ls sent
Mine	workspace.configuration: true, window.workDoneProgress: true	2 (workspace/configuration, window/workDoneProgress/create)
Second	configuration: false, window omitted entirely	0

Both got full cross-project navigation. So csharp-ls respects declared client capabilities — it only asks for what the client claims to support, and tolerates -32601 when it asks anyway. Claude Code declares nothing, which puts it in the second row.

Recommend asking upstream to retest #1359 against 0.27.0 and close it as fixed-upstream.

2. Licensing passes — Roslyn is not disqualified

This was the hard gate, and it clears. <license type="expression">MIT</license> sits in the nuspec of both roslyn-language-server and the exact Microsoft.CodeAnalysis.LanguageServer.<rid> packages this issue named. The 71 MB nupkg contains no EULA. The C# Dev Kit proprietary licence governs a component a Claude Code plugin would never install.

3. Roslyn does NOT require solution/open — a mid-run reversal worth reading

An intermediate probe showed Roslyn returning null for cross-project definition without solution/open, which reads as "needs a non-standard notification, therefore undrivable by a stock client." A control probe falsified that: --autoLoadProjects alone restored full cross-project navigation. The earlier failure came from passing neither loading mechanism, not from the absence of solution/open specifically.

Recording it because the wrong version is the intuitive one — solution/open exists, OpenSolutionHandler is real, and the community wrappers all send it. The measurement says it is not mandatory.

So the choice is on merit, not compatibility. Both servers are drivable by Claude Code's stock client.

The recommendation

csharp-ls, pinned >= 0.24.0 (currently 0.27.0).

• Needs none of the three handlers, no flags, no custom notifications. Workspace folders from initialize are enough.
• Solution path, when it matters, is a plain CLI flag: csharp-ls --solution Foo.sln. Roslyn needs the plugin to remember --autoLoadProjects.
• MIT, native .exe on Windows, small.

Roslyn / roslyn-language-server is a viable second choice, ranked lower purely on operational cost: 71 MB package, slower cold start, an extra required flag, prerelease-only versioning (--prerelease), and reported unreliability at ~60-project scale (claude-code#38683). Not on capability.

Also rejected, with reasons

Rejected	Why
A three-handler proxy shim	Solves a problem csharp-ls no longer has. Dead code guarding requests that are never sent.
OmniSharp	Last release v1.39.15 (2025-11-14); no longer VS Code's default. Currency judgment, not correctness.
SofusA/csharp-language-server (the Rust wrapper from the community workarounds)	Archived 2026-02-07, superseded by Microsoft's own roslyn-language-server.
techee/lsp-proxy	Generic multiplexer; does not synthesize server→client responses. Also GPL-2.0.

If Roslyn is wanted anyway, reuse ClaudeCodeRoslynLspProxy 0.3.0 (MIT, ships its own Claude Code plugin) rather than writing one — but verify provenance, it is an individual's package. It documents its own ceiling: Claude Code's LSP tool exposes read-only operations, so no proxy can add rename, codeAction or formatting.

Carry-forward for the plugin, whichever server wins

Set DOTNET_ROOT in the server's spawn environment. Independently hit by both probes: the apphost aborts with You must install .NET to run this application before emitting any LSP bytes, so it presents as a silent protocol failure rather than a launch error. Claude Code spawns without a shell or profile. The manifest supports an env block, which is the natural place for it.

A forward-compatibility bug worth filing upstream

If Claude Code ever declares window.workDoneProgress: true without implementing the handler, it would newly break Roslyn: WorkDoneProgressManager.SendCreateRequestAsync awaits the client with no try/catch, and OpenSolutionHandler calls it on the solution-load path. Claude Code is safe today only because it declares nothing. Capability declarations and handler implementations have to land together.

What is still unestablished

1. Scale. Every probe used 1–2 tiny projects. claude-code#38683 reports trouble at ~60 projects; nothing here confirms or refutes it. This is the one place a proxy might still earn its place.
2. Windows, directly. No Windows machine in session. The .exe conclusion is direct for roslyn-language-server (binary present in the win-x64 package) and one inferential step for csharp-ls.
3. Feature depth. Whether csharp-ls matches Roslyn on Razor, source generators and analyzers at scale. Not a compatibility question, but it is the real trade-off behind recommending the smaller server.
4. dotnet/roslyn#71474 maintainer replies (page rendered without comment bodies) and the C# Dev Kit EULA end-to-end. The MIT determination does not rest on either.
5. api.github.com was 403 through the egress proxy throughout — all GitHub evidence came from raw.githubusercontent.com and rendered HTML. Checked-but-blocked, not absent.

Artifact gate: exit 0, sidecars=7 missing=0 pointer=matches. Freshness reported unchecked — I skipped the pre-dispatch baseline touch on this slice, and the slice was new, so nothing stale could have passed it. One correction applied to the artifact: its recommendation header still encoded the falsified solution/open claim, contradicting its own addendum; corrected in place and marked as a parent correction.

---

Generated by Claude Code

[kyle-sexton]

Windows confirmed: csharp-ls installs as a native .exe

Measured on the Windows desktop, which closes the one inferential step in the research:

dotnet tool install --global csharp-ls
Tool 'csharp-ls' (version '0.27.0') was successfully installed.

where.exe csharp-ls
C:\Users\KyleSexton\.dotnet\tools\csharp-ls.exe

Direct evidence now, not one step removed from the Linux apphost mechanism. The Windows shell-spawn defect that breaks #3537 does not apply to C# — there is no .cmd in the path, and Claude Code can spawn this without a shell.

That was listed under "What could NOT be established" in the research comment above. It can be struck.

Also settled: version

The installed version is 0.27.0 — above the >= 0.24.0 floor the recommendation asks for, and the same build both probes ran against. No pin work needed for this machine; the floor still belongs in whatever we ship, since the field reports are mostly people on older builds.

What is left on this issue

1. Does the plugin actually light up? csharp-lsp@claude-plugins-official is now seeded (merged in melodic-software/dotfiles#609) but needs chezmoi apply and then a real check: open a .cs file in a multi-project solution and confirm the LSP tool registers and answers navigation. This is the only remaining unknown of substance.
2. DOTNET_ROOT. Still worth watching. On this machine dotnet is presumably in the default location, so the apphost should resolve the runtime without help — but Claude Code spawns without a shell or profile, so if the tool works from a terminal and not from Claude Code, this is the first thing to check. The symptom is silence, not an error: the apphost aborts before emitting any LSP bytes.
3. Scale. Unchanged and still the real open question. Both probes used two tiny projects. A production solution is the test that matters, and claude-code#38683 reports trouble at ~60 projects.

The server-selection recommendation (csharp-ls over Roslyn, on operational cost rather than capability) is unaffected by any of this.

---

Generated by Claude Code

[claude]

This was generated by AI during triage.

Decision-ready summary — the blocking open question is answered; the gate should narrow, not lift

Lane: autonomous triage, instance vm-triage-202609050304. No labels changed.

State of play — three of the issue's premises have reversed on this thread

The issue opens by declaring one question blocking: "Which C# language server? Do not assume csharp-ls just because Anthropic's plugin uses it." The thread answers it, and in doing so reverses the issue's framing:

1. The premise did not reproduce. A client that refuses the very requests upstream miro: setup skill omits the headless --config seeding path required by PLUGIN-PHILOSOPHY #1359 blames still got working cross-project C# intelligence on csharp-ls 0.27.0 (Linux x64, .NET SDK 10.0.400). The experiment was run rather than the upstream diagnosis inherited.
2. The blocker is a stale-version artifact. miro: setup skill omits the headless --config seeding path required by PLUGIN-PHILOSOPHY #1359 was filed against csharp-ls 0.16.0.0; the relevant fixes shipped in 0.22.0 (2026-02-05). The issue's "no fix in the Claude Code changelog through 2.1.252" search was looking on the wrong side — the fix was in the server, not the client.
3. Windows is confirmed, directly. dotnet tool install --global csharp-ls → csharp-ls.exe at C:\Users\KyleSexton\.dotnet\tools\. A native .exe, measured on the Windows desktop, not inferred from the Linux apphost.

Server selection is settled: target csharp-ls >= 0.24.0, write no shim. That closes the issue's own gating question and removes the shim from the critical path.

What the acceptance criteria still require

Reading the issue's acceptance list against the thread:

Criterion	State
A named server, reasoning recorded, rejected alternatives named	Met — csharp-ls >= 0.24.0, with the version history and the Roslyn Microsoft.CodeAnalysis.LanguageServer comparison on the thread
Windows: LSP tool appears; documentSymbol, hover, goToDefinition, findReferences correct in a real multi-project solution	Not met — executable form is confirmed; behaviour in a real solution is not
Same on WSL/Linux, or a recorded Windows-only decision	Partly — Linux cross-project intelligence was demonstrated; not recorded as a decision
No cli.js patching	Held (no shim needed)
Operator-install steps documented in one place	Not done

The outstanding criterion is the one the issue is emphatic about: "not a toy one, since solution loading is exactly what fails today." That is deliberate, and it should not be waived — solution loading is the specific thing the original upstream report says aborts.

Recommendation

RECOMMENDED — keep the gate, but narrow this issue to the validation-and-document step and record that server selection is closed.

Concretely:

1. Post a short closing note on the selection question so the next reader does not re-run the comparison: server = csharp-ls >= 0.24.0; shim = not required; upstream miro: setup skill omits the headless --config seeding path required by PLUGIN-PHILOSOPHY #1359 = stale-version artifact, fixed in 0.22.0.
2. Retitle from "pick the server, then get it working on Windows" to something like "validate csharp-ls on a real multi-project Windows solution and document the install" — the first half of the current title is done.
3. Keep needs-human. See below.
4. Consider dropping work-class: structural to work-class: scoped. The structural classification was earned by the open server-selection question and the prospective shim. With both gone, the residual is validation plus documentation. This is a reversible re-band and a maintainer should confirm it.
5. priority: high should stay. The issue's rationale holds: C# is this fleet's primary ecosystem and it currently has no language server at all, so every C# edit goes without diagnostics or navigation. That is unchanged and is now closer to being fixable, which argues for keeping it hot.

Why the gate should NOT be lifted, even though the hard question is answered

Two reasons, either sufficient:

• The remaining work is manual QA on a specific host. It requires a real multi-project C# solution on a Windows desktop and a human observing whether hover, go-to-definition and find-references return correct results. That is a capability constraint, not a specification gap — the exact case the human-gated exit is reserved for.
• An install decision reaches beyond this repo. "Whatever the operator must install by hand is documented in one place" plus the likely dotfiles-seeding follow-on (the issue records that csharp-lsp was deliberately kept out of the dotfiles seed) is a fleet-provisioning change, and the sibling pyright-lsp may be silently dead on Windows — verify before assuming Python coverage works #3538 thread points the same way — prefer fixing the install form over shipping a wrapper.

One caution for whoever validates

The thread's Linux result and the Windows .exe result are different claims, and neither is the acceptance criterion. Linux showed working cross-project intelligence; Windows showed a spawnable native binary. The criterion asks for behaviour in a real multi-project solution on Windows, which is the intersection and has not been demonstrated. Do not let the two partial results be read as jointly satisfying it — that is precisely the inferential shortcut sibling #3538 was opened to guard against.

---

Generated by Claude Code