C# Code Intelligence in Claude Code: Setup and Limits
Nick Cosentino explains how to set up C# code intelligence in Claude Code through the csharp-lsp plugin and where that setup stops being reliable. The article separates the language server, the plugin and the workspace as three layers to verify, and it clarifies what diagnostics and symbol navigation can and cannot prove. It is a practical checklist for .NET developers using Claude Code on C# repositories.
Key points
- Verify that csharp-ls resolves in the same shell that launches Claude Code (for example with Get-Command csharp-ls); an executable-not-found error is a PATH problem, not a plugin problem.
- Install the server with dotnet tool install --global csharp-ls, but note that the plugin README lists .NET SDK 6.0+ while the server docs require the .NET 10 SDK or later.
- Install the plugin inside a Claude Code session with /plugin install csharp-lsp@claude-plugins-official and check the Errors tab under /plugin if nothing appears.
- Treat a diagnostics summary as ambiguous until you know which tool produced it, which file it covers and whether the right project was loaded.
- Plugin language servers do not run in cloud sessions, so do not claim semantic navigation happened there.
- Keep compiler, test and language-server evidence separate in reviews; a clean LSP report is not a build result.
Code intelligence lets Claude Code move from plain text search to symbol-level navigation through a language server, and it can receive diagnostics after edits to C# files. The author stresses that this setup has three layers that fail independently: the csharp-ls executable must be launchable, the csharp-lsp plugin must be active in Claude Code, and the server must load the right workspace. Checking each layer separately avoids reinstalling the plugin when the real problem is a missing executable path.
The piece also draws firm limits. A silent diagnostics panel does not prove the code compiles, and editor inspections, language-server output and compiler results are different evidence sources. The documented plugin servers do not start in cloud sessions, so teams should not assume the same capabilities there. Recording the server version, Claude Code version and launch environment makes later failures easier to reproduce.
Real-world use
- In a large ASP.NET Core solution, finding which implementation satisfies the interface an endpoint handler depends on, then confirming registration in the composition root.
- Locating every place a response record is constructed, where plain text search returns noisy matches from common names.
- Standardizing a team's Claude Code setup by documenting the plugin, server, SDK and launch shell so failures can be reproduced.
Why it matters
If you rely on Claude Code for C# changes, you need to know which layer produced each result, since a missing executable, an unloaded workspace or a cloud session can each look like a clean run. Verifying the setup layer by layer and still running the compiler and tests keeps agent-driven edits trustworthy.