Desktop app never registers plugin LSP servers, though the bundled CLI resolves them (csharp-lsp, 1.40609.0 / CCD 2.1.247, Windows)

Summary

On the Claude desktop app, a plugin-declared LSP server is never registered: no LSP tool is
exposed to the session, no server process is spawned, and not a single LSP-related line appears
in any app log. The bundled CLI at the same version resolves the very same plugin correctly —
claude plugin details reports LSP servers (1) csharp-ls — so this is not the missing-manifest
class of bug already tracked in #78604 / #84857 / #90114 / #15148.

Environment

| | |
|---|---|
| Desktop app | 1.40609.0 |
| CCD / CLI | 2.1.247 |
| Node | 24.18.1 |
| OS | Windows 10 Pro 19045 |
| Plugin | csharp-lsp@claude-plugins-official v1.0.0, enabled, user scope |
| Server binary | csharp-ls 0.27.0 at C:\Users\admin\.dotnet\tools\csharp-ls.exe, on PATH |
| Project | 6-project C# solution (.slnx), ~80k LOC |

Evidence

The plugin resolves correctly — from the CLI

> claude plugin details csharp-lsp@claude-plugins-official
csharp-lsp 1.0.0
  Description: C# language server for code intelligence
  Source: csharp-lsp@claude-plugins-official

Component inventory
  Skills (0)
  Agents (0)
  Hooks (0)
  MCP servers (0)
  LSP servers (1)  csharp-ls  (out-of-process tooling; no model context cost)

So the lspServers declaration in marketplace.json is being picked up, even though the
cached .claude-plugin/plugin.json does not contain it (see "Note on the related issues" below).

In a desktop-app session, nothing happens

1. No LSP tool is exposed. Probing three deferred tools in one request returns two:

``
ToolSearch "select:WebFetch,LSP,ListSkills" -> WebFetch ✔, ListSkills ✔, LSP ✘ (no match)
``

Keyword searches ("lsp", "language server definition references csharp") also return
nothing LSP-related.

1. No server process, including after opening a .cs file in the session:

``
> Get-CimInstance Win32_Process -Filter "ParentProcessId=<claude pid>"
ProcessId Name
--------- ----
16904 conhost.exe
35820 pwsh.exe
``

Get-Process csharp-ls → nothing, at any point.

1. Zero LSP lines in the logs. Grepping every file in

%LOCALAPPDATA%\Claude\logs\ for lsp server|LSP servers loaded|lspServers|language server
returns no matches at all — the app never even attempts to start one. For contrast, the same
log is verbose about the plugin loading fine:

``
2026-08-31 10:19:04 [info] [CCD] Passing 10 plugin(s) to SDK (skills: 1, remote: 0, local: 9)
2026-08-31 10:29:51 [info] [CCD] reload_plugins applied for local_...: 10 plugin(s), 99 command(s), 0 plugin error(s)
``

The server itself is healthy

Driven directly over stdio with a small LSP client, csharp-ls 0.27.0 loads the solution and
answers normally against this project:

[  4.0s] Finished loading solution "...\ESS.slnx"
   workspace/symbol 'DeviceCategory'  -> 3
   documentSymbol                     -> 9
   hover                              -> ```csharp DeviceCategory``` …
   references                         -> 12

So neither the binary, the PATH, nor the project is the obstacle.

Expected

With the plugin enabled and the declared command resolvable on PATH, a desktop-app session
should expose the LSP tool and start the server on demand, as the CLI's own
plugin details output implies it will.

Actual

The plugin loads with 0 plugin error(s), reports one LSP server via plugin details, and
silently provides nothing. Nothing in the UI, the session, or the logs indicates that the
advertised capability is inactive.

Note on the related issues

#78604, #84857, #90114 and #15148 all describe the cached
.claude-plugin/plugin.json being generated with only name/description/version/author, so the
lspServers block is lost. That file state reproduces here too — and I can add one datapoint the
others were unsure about: the generated file is rewritten on every marketplace refresh, not
only on install/update. A manually restored lspServers block survived three minutes, until
opening the plugins panel triggered:

2026-08-31 10:29:48 [info] [CCDMarketplacePluginManagerCLI] Refreshing marketplace: claude-plugins-official
2026-08-31 10:29:49 [info] [marketplaceFileOps] Synthesized plugin.json for csharp-lsp (strict:false marketplace plugin)

Synthesis keeps four keys and drops three: category, strict, lspServers.

But that is apparently not what blocks this case, since plugin details still resolves the
server from the marketplace entry. The desktop app appears not to consume that resolution at all.
Filing separately so the two do not get conflated; happy to have this closed as a duplicate if
they share a root cause.

Impact

All 12 official *-lsp plugins advertise code intelligence that never engages in the desktop app,
with no error surfaced anywhere. On an 80k-line solution this is the difference between real
symbol navigation and plain text search — and because the plugin reports as healthy, there is no
way for a user to tell it is doing nothing.