C# code intelligence in Claude Code helps an agent ask more precise questions about a repository. Instead of searching only for a method's spelling, it can navigate through a language server to definitions and references. It can also receive diagnostics after edits to supported files.
That does not make the language server a replacement for your compiler, tests, or review. It adds an evidence source with its own installation, workspace, and environment boundaries. Understanding those boundaries is the difference between useful feedback and a misleading “no errors” conclusion.
Information checked October 9, 2026. Plugin behavior and prerequisites were checked online against official documentation and the official plugin README; no plugin installation or C# sample execution was performed.
What the C# plugin actually connects
The current official code intelligence documentation lists csharp-lsp as the C# plugin and csharp-ls as its server binary. The plugin tells Claude Code which command starts the language server and which extensions it handles.
The language server is a separate process. The plugin does not include that binary. Installing the plugin alone therefore does not establish working C# navigation. Installing the server alone likewise does not establish that Claude Code has loaded the matching plugin.
The official C# plugin README lists .cs as the supported extension. Do not infer that every Razor, project, JSON, or SQL file receives equivalent semantic analysis from this plugin.
The documented connection uses the Language Server Protocol. That describes how the client and server communicate. It does not establish that Claude automatically shares your editor's workspace, uses the same inspection settings, or has inspected every project in a multi-project solution.
These are important distinctions for .NET applications, where C# code interacts with project configuration, generated source, dependency injection, and framework conventions. Navigation through source symbols can illuminate part of that system without proving the entire runtime arrangement.
Separate the server, plugin, and workspace
Think of code intelligence as three layers. First, the language-server executable must be installed and launchable. Second, the Claude Code plugin must be installed and active. Third, the server must load the intended workspace well enough to provide meaningful results.
A failure at the first layer can appear as an executable-not-found error. A failure at the second can leave Claude using text search even though the server exists. A workspace problem can produce missing or misleading diagnostics after both installations appear successful.
This layered model avoids a common troubleshooting mistake: reinstalling the plugin when the real problem is an executable path, or changing source code because a server loaded an incomplete project.
The same reasoning applies when testing an MCP server independently of its host connection. A functioning component and a functioning integration are related facts, not interchangeable facts.
For the C# plugin, verify each layer explicitly and record which environment supplied the result. A Windows shell, a WSL shell, and a remote runner can resolve different executables even when they access related source files.
Install the server only after checking compatibility
The official C# plugin README documents installation through the .NET tool command:
dotnet tool install --global csharp-ls
This command installs a tool and is not a read-only inspection step. Use it only in an environment where tool installation is approved. It is shown here as the documented installation path, not as an executed result.
The plugin README states a .NET SDK requirement of 6.0 or later, but the language server's current own installation documentation requires the .NET 10 SDK or later. Those sources disagree. For a current installation, consult the server's requirements and the selected package version rather than assuming the plugin README is a complete compatibility matrix.
The SDK hosting the server is also distinct from the frameworks targeted by the projects it analyzes. The server documentation describes support for older project targets; installing its required SDK does not require retargeting the application. No package version was installed here, so resolved-package compatibility remains an execution check.
Global installation is also an environment choice. It makes the server available to the current user's tool environment, but the process launching Claude must still see its executable path. An IDE or long-running terminal may have inherited a different environment.
A useful read-only visibility check in PowerShell is:
Get-Command dotnet
dotnet --info
dotnet tool list --global
Get-Command csharp-ls
These commands identify the .NET environment, installed global tools, and command resolution. They do not prove the server has loaded your solution. If Get-Command csharp-ls fails, fix executable visibility before asking the model to explain missing diagnostics.
Avoid making a project-level SDK change just to satisfy an unexamined global tool. The tool's runtime and the application's target framework are different concerns. Resolve the environment deliberately, then preserve the repository's version policy.
Install the official plugin in Claude Code
The official code intelligence page demonstrates terminal plugin installation with a name@marketplace identifier. Applying its listed C# plugin name gives this command inside a Claude Code session:
/plugin install csharp-lsp@claude-plugins-official
This is a Claude Code command, not a PowerShell command. The distinction matters when documenting setup: a shell cannot interpret the slash command as a plugin operation.
The current docs say the confirmation tells you whether the plugin is active immediately or requires /reload-plugins. Follow the actual result instead of assuming the same reload behavior for every version and installation path.
If the official marketplace is not found, use the troubleshooting link from the current documentation. Do not replace the plugin with an arbitrary similarly named package just to produce a successful installation message.
The official page gives different installation guidance for the VS Code extension and desktop app. The terminal command here describes the terminal route. It should not be presented as proof that a graphical surface uses the same installation interaction.
Record the plugin identity, server version, Claude Code version, and launch environment when validating setup. Those facts make a later failure reproducible without claiming that the entire toolchain is permanently fixed.
Verify behavior in a disposable, representative workspace
The official documentation says the server starts the first time Claude edits a file matching the plugin's extensions. It describes checking the conversation for a diagnostics line after introducing and fixing a type error.
That is a verification procedure, not an instruction to introduce an error into production work. Use an approved disposable workspace or a controlled branch, preserve the baseline, and ensure any temporary edit is removed.
The following C# file is an unexecuted illustration of a deliberate type error. It would need to live in an appropriate scratch project selected for validation:
namespace Scratch;
public sealed class DiagnosticProbe
{
public int ReadCount()
{
return "not an integer";
}
}
The example's return expression conflicts with the declared int return type. Its purpose is to produce a known diagnostic trigger, not to demonstrate a working application. A successful setup check would observe the expected feedback, then replace the return expression with an integer and inspect the resulting diagnostic state.
The documentation names the summary format Found N new diagnostic issues in M files and says Ctrl+O expands the details. A summary alone is not enough to understand a reported issue. Inspect the file, position, message, and relevant workspace.
Do not treat a deliberately broken snippet as compilation evidence. This article did not run it. Nor does the absence of a summary prove correctness: the server may not have started, the file may not have loaded, or the supported analysis may not cover the relevant behavior.
Use symbol navigation for source relationships
The official tools reference identifies the LSP tool for code intelligence, including definition and reference navigation. The code intelligence page describes it as read-only navigation through the server.
For a .NET endpoint task, a useful navigation question is: which implementation satisfies the service interface called by this handler? Another is: where else is the response record constructed? These are relationships that text search may approximate but cannot always disambiguate.
Overloaded methods, common property names, and repeated interface names make lexical results noisy. Symbol navigation can supply a more precise starting point, after which the agent still needs to read the relevant implementation and tests.
Do not infer runtime registration from source references alone. A service can be registered conditionally, loaded through a plugin, or selected by configuration. The agent must inspect the composition root and applicable registration code to understand which implementation runs.
For an integration-heavy application such as an ASP.NET Core agent client, transport ownership and lifecycle cannot be proven by jumping to one interface definition. Navigation is a discovery tool; integration evidence remains separate.
Keep text search in the workflow
Language-server navigation is not universally better than text search. It is better suited to questions about recognized source symbols. Route strings, configuration keys, documentation references, SQL fragments, and build properties often need lexical inspection.
For example, finding a route's external URL may begin with a string search. Once the handler is located, symbol navigation can trace its service calls. Tests can then show how the route is actually exercised.
This combined approach is especially useful when reviewing ASP.NET Core middleware and endpoint behavior. The execution pipeline includes configuration and ordering that a symbol lookup does not automatically explain.
Ask the agent to name how it found a relationship when that distinction matters. “Found three references” is different from “searched for the string and reviewed three matches.” Both can be useful, but they support different confidence levels.
The goal is not to force every lookup through LSP. It is to choose the evidence source that matches the question and avoid overstating what that source proves.
Distinguish three kinds of diagnostics
Editor inspections, plugin language-server diagnostics, and compiler output are separate evidence sources. They may use related underlying concepts, but this article does not assume identical project loading, configuration, or timing.
The official JetBrains integration documentation says Claude can read IDE inspections through getDiagnostics and explicitly notes that the plugin does not request diagnostics automatically after edits. The code intelligence documentation, by contrast, describes automatic feedback after edits handled by the language server.
A report that merely says “IDE diagnostics passed” is therefore ambiguous. Which tool supplied the feedback? Did it analyze the changed file? Was the relevant project loaded? Were warnings or generated-source issues omitted?
Compiler evidence should identify the build command and environment. Behavioral evidence should identify the test and what it asserted. Neither should be replaced by the phrase “LSP is green.”
This distinction complements unit and integration testing boundaries. A source diagnostic catches some structural problems; an HTTP integration test checks another layer of behavior.
Understand the cloud-session limit
The current official code intelligence page states that plugin language servers work in terminal sessions and do not start in cloud sessions. It explicitly says those cloud sessions receive no diagnostics or navigation from these plugin servers.
That is a significant boundary for documentation and handoffs. A local demonstration should not be described as proof that a cloud task has the same capabilities. A cloud agent may still inspect files and use other available tools, but those are different evidence paths.
Do not hide the difference by saying that all Claude Code surfaces share the same engine. Shared product branding and underlying components do not erase documented per-surface limitations.
If a task relies on symbol navigation, record whether that capability was actually available. If it was not, the agent can explain that it used text inspection instead and avoid claiming semantic navigation occurred.
Likewise, remote validation does not have to mean a Claude cloud session. An approved CI runner can compile and test a revision independently. Keep the agent's discovery environment and the validation environment distinct in the evidence record.
Troubleshoot missing or misleading feedback
The official code intelligence page directs users to the Errors tab under /plugin when diagnostics do not appear. An Executable not found in $PATH message identifies a missing or invisible server binary.
After installing a missing binary, the docs say Claude Code retries when a matching file is edited. If the executable directory was not visible to the shell that launched Claude, start a new session from a shell where it resolves.
If no executable error appears, investigate plugin activation and workspace loading rather than assuming silence means success. The official troubleshooting guidance also names high indexing memory use and false unresolved-import diagnostics in monorepos as possible symptoms.
Do not respond to unresolved imports by deleting valid dependencies until authoritative build evidence is considered. A diagnostic can be useful and still be wrong for an incompletely loaded workspace.
Finally, tests should target real behavior, not merely the tool's output. Failure-path testing remains necessary even when the editor and language server report no source errors.
Frequently asked questions
What is the official C# plugin called?
The fetched official table lists csharp-lsp, with csharp-ls as the separate server binary. The plugin README lists .cs as its supported extension.
Does installing the plugin install the server?
No. The official documentation explicitly says the plugin does not include the language server. Install and verify the binary separately in the launch environment.
Is the README's SDK requirement a full compatibility guarantee?
No. The plugin README says SDK 6.0 or later, while the server's current documentation requires SDK 10 or later. Check the server and selected package version. No resolved package was installed or validated here.
Does code intelligence replace text search?
No. Symbol relationships benefit from language-server navigation, while route strings, configuration, and documentation often need lexical search. Use both where appropriate.
Does the plugin run in Claude Code cloud sessions?
The current official docs say plugin language servers do not start there. Do not attribute local plugin diagnostics or navigation to a cloud session.
Do clean diagnostics prove a change is correct?
No. They provide feedback from a particular workspace and tool. Compilation, behavioral tests, integration checks, and human review establish additional parts of the contract.
Code intelligence improves discovery, not certainty
C# code intelligence in Claude Code is valuable when its role is explicit: connect a known server, load the intended workspace, navigate symbols, and inspect diagnostics. Each result should remain attached to its environment and scope.
That makes the feature useful without asking it to prove things it cannot prove. The application still needs meaningful verification, and the final review still needs to establish that the requested behavior was preserved.