dotnet plugin's C# LSP never loads in Claude Code — manifest is at root plugin.json, but Claude reads lspServers only from .clau [Content truncated due to length]

[hgirma]

Summary

The dotnet plugin declares a C# (Roslyn) language server via lspServers, but it never loads in Claude Code: Total LSP servers loaded: 0. The plugin's skills load fine, which masks the problem.

Root cause: Claude Code reads a plugin's manifest — and therefore its lspServers field — only from <pluginRoot>/.claude-plugin/plugin.json. The dotnet plugin instead ships its manifest at the repo-root plugin.json (plus a .codex-plugin/plugin.json for Codex) and has no .claude-plugin/plugin.json. So Claude never sees lspServers. Skills still appear because Claude auto-discovers them from skills/*/SKILL.md frontmatter, independently of the manifest — so only the LSP (the one manifest-only feature) is silently broken.

Environment

• Claude Code @anthropic-ai/claude-code 2.1.195 (observed on Windows 11, but this is OS-independent)
• Marketplace dotnet-agent-skills (this repo), plugin dotnet
• .NET SDK 10.0.301; dnx on PATH; dnx roslyn-language-server --yes --prerelease -- --stdio --autoLoadProjects launches Microsoft.CodeAnalysis.LanguageServer.exe fine when run manually

Repro

1. Install the dotnet plugin and enable it.
2. Launch claude --debug with CLAUDE_CODE_DEBUG_LOGS_DIR set, then open/edit a .cs file.
3. Grep the debug log:
   • Total LSP servers loaded: 0
   • No per-plugin LSP load attempt is logged (none of LSP server(s) from plugin:, Failed to read/parse .lsp.json in plugin, Missing environment variables in plugin LSP config:). The loader never treats dotnet as an LSP source.
   • The dotnet skills do load.
4. No Microsoft.CodeAnalysis.LanguageServer.exe / dnx process is spawned.

Evidence that the manifest location is the cause

• Claude Code's plugin loader requires the manifest at .claude-plugin/plugin.json (".claude-plugin/plugin.json is always required"; "No manifest found in directory. Expected .claude-plugin/marketplace.json or .claude-plugin/plugin.json").

• Every first-party Claude Code plugin (e.g. superpowers, telegram, frontend-design) places its manifest at .claude-plugin/plugin.json and has no root plugin.json.

• Every dotnet/skills plugin does the opposite — root plugin.json, no .claude-plugin/plugin.json:

  plugin	.claude-plugin/plugin.json	root plugin.json	.codex-plugin/plugin.json	lsp.json
  dotnet	❌	✅	❌	✅
  dotnet-ai / -aspnetcore / -blazor / -test / dotnet11	❌	✅	✅	❌
  dotnet-data / -diag / -maui / -msbuild / -nuget / -aspnet	❌	✅	❌	❌

Likely fix (verification in progress)

Ship a .claude-plugin/plugin.json for each plugin — at minimum for dotnet, which declares the LSP — the same way .codex-plugin/plugin.json is already provided for Codex. The content can mirror the existing root plugin.json:

{
  "name": "dotnet",
  "version": "0.1.0",
  "description": "Common everyday C#/.NET coding skills. Expected to be useful to all .NET developers.",
  "skills": ["./skills/"],
  "lspServers": "./lsp.json"
}

I'm validating locally by dropping exactly this .claude-plugin/plugin.json into the installed plugin and checking for Total LSP servers loaded: 1 + a spawned server process; will update this issue with the confirmed result.

Optional hardening: inline the server config under lspServers (record form) instead of the "./lsp.json" string path, e.g.

"lspServers": {
  "csharp": {
    "command": "dnx",
    "args": ["roslyn-language-server", "--yes", "--prerelease", "--", "--stdio", "--autoLoadProjects"],
    "cwd": "${PLUGIN_ROOT}",
    "fileExtensions": { ".cs": "csharp", ".razor": "aspnetcorerazor", ".cshtml": "aspnetcorerazor" },
    "startupTimeout": 120000
  }
}

Impact

Anyone using the dotnet plugin in Claude Code for C# LSP gets no language-server intelligence (diagnostics, go-to-definition, hover, symbols) and no indication why — skills load, so the plugin looks healthy. The same root-level manifest affects all dotnet/skills plugins, but it's only observable for dotnet because that's the only one with manifest-only functionality (lspServers); the rest rely on skills, which auto-discover regardless.

[github-actions]

🎯 Issue Triage

Summary: The dotnet plugin's Roslyn/C# language server silently fails to load in Claude Code because the plugin manifest is located at the repo-root plugin.json rather than .claude-plugin/plugin.json, which is where Claude Code exclusively reads lspServers from. Skills load fine (via frontmatter autodiscovery), masking the breakage. The fix is to add a .claude-plugin/plugin.json to the dotnet plugin that mirrors the existing manifest and includes the lspServers reference.

Type: Bug

Assigned owners: @webreidi, @AbhitejJohn (default owners). Teams that should be looped in per CODEOWNERS: @dotnet/roslyn-ide and @dotnet/skills-csharp-language-reviewers (owners of /plugins/dotnet/lsp.json — cannot be directly assigned as teams).

Confidence: High — clear root cause with repro steps, well-scoped area, obvious type.

Similar issues: #454 ("Roslyn Language Server not working with Claude Code") is a closely related open issue covering the same functional failure from a slightly different angle (lsp.json format). This issue provides a more complete root-cause analysis and may supersede or complement #454.

Triage details

• Area mapping: Issue is about plugins/dotnet/ manifest structure and lsp.json — maps to area-dotnet. The specific CODEOWNERS path match for lsp.json is /plugins/dotnet/lsp.json.
• CODEOWNERS path match: /plugins/dotnet/lsp.json → @dotnet/roslyn-ide @dotnet/skills-csharp-language-reviewers; catch-all `*` → `@webreidi `@AbhitejJohn
• Confidence rationale: Issue has a well-articulated root cause, clear repro, table of evidence across all plugins, and a concrete proposed fix. Type is unambiguously a bug (LSP silently broken despite plugin appearing healthy).
• Suggested next steps: Create .claude-plugin/plugin.json for the dotnet plugin (at minimum); consider whether all plugins need this directory for correct Claude Code manifest loading. Review Roslyn Language Server not working with Claude Code #454 to determine if the two issues should be consolidated.

Generated by Issue Triage for issue #846 · 89.3 AIC · ⊞ 26.8K · ◷

[nicholasptran]

chat, link pr to issue #598

[hgirma]

Update: verified end-to-end — the .claude-plugin/plugin.json fix is necessary but not sufficient. Three stacked bugs, all now confirmed fixed.

Adding .claude-plugin/plugin.json (the original root cause) only uncovers two further problems. I verified all three against @anthropic-ai/claude-code 2.1.195 (Windows 11) by forcing the spawn headlessly and reading the debug log (CLAUDE_CODE_DEBUG_LOGS_DIR=<file>; claude --debug --permission-mode acceptEdits -p "<edit a .cs, then summarize several files>" — the lazy connect fires ~15s after a .cs edit, so the session has to stay alive long enough).

Cause #1 — manifest location (as filed)

Adding <pluginRoot>/.claude-plugin/plugin.json makes Claude read lspServers at all. ✅ Required.

Cause #2 — the lsp.json schema is wrong for current Claude Code (this is also #454)

With the manifest in place, the next debug line was:

Validation errors: lspServers: Invalid input
Total LSP servers loaded: 0

Claude Code 2.1.195 validates each server against a strictObject (no unknown keys allowed). The permitted keys are:

command, args, extensionToLanguage (required, Record<extension, languageId>, ≥1 entry), transport ("stdio"|"socket", default stdio), env, initializationOptions, settings, workspaceFolder, startupTimeout, shutdownTimeout.

The current plugins/dotnet/lsp.json uses fileExtensions and cwd — both are unknown keys, so the strict validation rejects the entire server → 0 loaded.

• fileExtensions → rename to extensionToLanguage (same { ".cs": "csharp", ... } shape).
• cwd → not a valid key. Drop it (the server defaults to the session cwd = project root, which is what Roslyn --autoLoadProjects wants); use workspaceFolder only if an explicit path is truly needed.

(There's also a .refine on command: it must not contain a space unless it starts with /, so an absolute Windows path like C:\Program Files\dotnet\... is rejected.)

Cause #3 — the spawn command must be a real executable

Claude spawns the LSP command without a shell, so it must be a directly-executable binary. Tested by actually triggering the spawn:

command	Result
dnx	spawn dnx ENOENT — there is no dnx.exe; only dnx.cmd/dnx.ps1, and a no-shell spawn doesn't do PATHEXT resolution
dnx.cmd	spawn dnx.cmd EINVAL — Node/Bun refuse to spawn .cmd/.bat without shell: true (post-CVE-2024-27980 behavior)
dotnet (with dnx as first arg)	✅ works

dnx.cmd is literally "%~dp0dotnet.exe" dnx %*, so invoking dotnet directly is equivalent and portable (it's a real PE/ELF executable on every platform).

Final config (verified)

This loads and spawns Roslyn. Recommend inlining it in .claude-plugin/plugin.json (and/or fixing lsp.json identically):

"lspServers": {
  "csharp": {
    "command": "dotnet",
    "args": ["dnx", "roslyn-language-server", "--yes", "--prerelease", "--", "--stdio", "--autoLoadProjects"],
    "extensionToLanguage": {
      ".cs": "csharp",
      ".razor": "aspnetcorerazor",
      ".cshtml": "aspnetcorerazor"
    },
    "startupTimeout": 120000
  }
}

Verified result

Loaded 1 LSP server(s) from plugin: dotnet
Total LSP servers loaded: 1
Starting LSP server instance: plugin:dotnet:csharp
Applied queued notification handler for plugin:dotnet:csharp.textDocument/publishDiagnostics
→ Microsoft.CodeAnalysis.LanguageServer.exe spawned

No validation errors, no EINVAL/ENOENT.

Net for the maintainers

Two files need to change for dotnet:

1. Add .claude-plugin/plugin.json (cause Initial documentation and validation workflow #1).
2. Fix the server config keys + command (causes test: validating validation #2/feat: Add WinForms Expert #3) — fileExtensions→extensionToLanguage, drop cwd, command:"dnx"→command:"dotnet" + "dnx" as the first arg. This second part is the same defect tracked in Roslyn Language Server not working with Claude Code #454.

[AbhitejJohn]

Thanks for reporting. This is addressed by #598 that was merged yesterday.