## Bug Description LSP servers from plugins are not being registered. The LSP Manager initializes with 0 servers before the plugins are loaded, so the `.lsp.json` configurations from LSP plugins are never picked up. ## Environment - **Claude Code Version:** 2.0.76 - **OS:** macOS (Darwin 24.6.0) - **Plugin:** `vtsls@claude-code-lsps` from `boostvolt/claude-code-lsps` marketplace ## Steps to Reproduce 1. Install vtsls globally: `npm install -g vtsls` 2. Add the claude-code-lsps marketplace t

LSP plugins not registering servers - LSP Manager initializes before plugins load

Status Fixed / completed

Reported on v2.0.76

Maintainer reply ✓ Yes — dhollman

Activity 8 comments · opened Dec 27, 2025 · closed Mar 12, 2026

💡 Likely answer: A maintainer (dhollman, contributor) responded on this thread — see the highlighted reply below.

Bug Description

LSP servers from plugins are not being registered. The LSP Manager initializes with 0 servers before the plugins are loaded, so the .lsp.json configurations from LSP plugins are never picked up.

Environment

Claude Code Version: 2.0.76
OS: macOS (Darwin 24.6.0)
Plugin: vtsls@claude-code-lsps from boostvolt/claude-code-lsps marketplace

Steps to Reproduce

Install vtsls globally: npm install -g vtsls
Add the claude-code-lsps marketplace to settings.json:

``json "extraKnownMarketplaces": { "claude-code-lsps": { "source": { "source": "github", "repo": "boostvolt/claude-code-lsps" } } }``

Enable the plugin: "vtsls@claude-code-lsps": true in enabledPlugins
Restart Claude Code
Try using the LSP tool on a TypeScript file

Expected Behavior

The LSP tool should work with TypeScript files using the vtsls language server.

Actual Behavior

LSP tool returns: No LSP server available for file type: .ts

Debug Log Evidence

The debug log shows the timing issue:

2025-12-27T16:09:35.099Z [DEBUG] [LSP MANAGER] Starting async initialization (generation 1)
2025-12-27T16:09:35.104Z [DEBUG] LSP server manager initialized successfully
2025-12-27T16:09:35.104Z [DEBUG] LSP notification handlers registered successfully for all 0 server(s)
2025-12-27T16:09:35.110Z [DEBUG] Plugin vtsls@claude-code-lsps version 1.0.0 already cached
2025-12-27T16:09:35.110Z [DEBUG] Loaded hooks from standard location for plugin vtsls

The LSP Manager completes initialization with 0 servers at 16:09:35.104, but the vtsls plugin doesn't finish loading until 16:09:35.110.

Plugin Configuration

The plugin's .lsp.json file at ~/.claude/plugins/cache/claude-code-lsps/vtsls/1.0.0/.lsp.json:

{
  "typescript": {
    "command": "vtsls",
    "args": ["--stdio"],
    "extensionToLanguage": {
      ".ts": "typescript",
      ".tsx": "typescriptreact",
      ".js": "javascript",
      ".jsx": "javascriptreact"
    }
  }
}

Additional Context

Plugin validates successfully: claude plugin validate returns "✔ Validation passed"
vtsls binary is installed and accessible: /usr/local/bin/vtsls (v0.3.0)
Multiple restarts of Claude Code don't resolve the issue
The same issue occurs with pyright@claude-code-lsps

Suggested Fix

The LSP Manager should either:

Wait for plugins to load before initializing
Re-scan for LSP configurations after plugins finish loading
Support lazy initialization of LSP servers when first needed

View original on GitHub ↗

8 Comments

github-actions[bot] · 8 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

dancehands · 8 months ago

Having same issue using the Intelephense plugin for PHP.

pdebuitlear · 7 months ago

Any update on fixing this issue please?

mkreyman · 6 months ago

Confirming this issue also affects the elixir-lsp@claude-code-elixir plugin (from georgeguimaraes/claude-code-elixir) on Linux.

Environment:

Claude Code Version: 1.0.33
OS: Ubuntu 24.04 (headless)
Plugin: elixir-lsp@claude-code-elixir (v1.0.1)
LSP binary: ElixirLS v0.30.0 (confirmed working standalone)

What I tested:

Marketplace-installed plugin with inline lspServers in plugin.json — plugin shows "Enabled" with no errors, but no "Components:" section and no LSP tools registered
Same plugin with lspServers pointing to a .lsp.json file — same result
--plugin-dir loading — fails with "Error: Marketplace 'inline' not found in configuration"

The official LSP plugins (typescript-lsp, pyright-lsp) work because they appear to be hardcoded/built-in — their cached plugin directories contain only a README and LICENSE, no plugin.json or .lsp.json.

This blocks all third-party LSP plugins regardless of configuration format.

tulensrma · 6 months ago

Confirming on Linux + official marketplace plugin (v2.1.63)

Same race condition confirmed. The LSP Manager completes initialization ~6 seconds before the versioned plugin system finishes loading.

Environment:

Claude Code v2.1.63 (latest as of 2026-02-28)
Ubuntu Linux (6.8.0-101-generic)
Plugin: pyright-lsp@claude-plugins-official v1.0.0 (project scope)
Binary: pyright-langserver installed via bun, confirmed in PATH
ENABLE_LSP_TOOL: "1" set in ~/.claude/settings.json

Debug log evidence (timestamps tell the story):

17:38:55.782Z  Loaded 15 installed plugins from installed_plugins.json
17:38:55.782Z  Found 0 plugins (0 enabled, 0 disabled)
17:38:55.814Z  [LSP MANAGER] Starting async initialization (generation 1)
17:38:55.815Z  Total LSP servers loaded: 0
17:38:55.815Z  LSP manager initialized with 0 servers
...
17:39:01.259Z  Initialized versioned plugins system with 15 plugins   ← 6 seconds too late

The LSP Manager queries plugins at t+32ms, but the versioned plugin system doesn't finish until t+5477ms. The marketplace manifest (marketplace.json) correctly defines the lspServers configuration for pyright, but it's never read because the LSP Manager has already given up.

What I verified:

Plugin shows as "Installed & Enabled" in /plugin UI
marketplace.json has correct lspServers entry with pyright-langserver --stdio command
Project-level .claude/settings.json has "pyright-lsp@claude-plugins-official": true
Every recent session debug log shows the same Total LSP servers loaded: 0 pattern

This is consistent across multiple restarts and sessions. The race condition appears deterministic, not intermittent.

vishnutskumar · 6 months ago

Confirming for third-party marketplace plugin (verible-lsp) on Linux v2.1.63

Same root cause confirmed — third-party LSP plugins with valid .lsp.json are silently ignored.

Environment:

Claude Code v2.1.63
Ubuntu 24.04 (Linux 6.8.0-101-generic)
Plugin: verible-lsp from custom GitHub-hosted marketplace
Binary: verible-verilog-ls v0.0-4007-g98bdb38a, installed and in PATH

Additional evidence — official plugins are hardcoded, not loaded from config:

Official LSP plugin cache directories (e.g. pyright-lsp) contain only a README and LICENSE — no .lsp.json, no plugin.json. Their LSP server definitions appear to be baked into the Claude Code binary. Third-party plugins that provide properly structured .lsp.json and plugin.json with lspServers fields are never read.

# Official plugin cache — no config files:
~/.claude/plugins/cache/claude-plugins-official/pyright-lsp/1.0.0/
├── LICENSE
└── README.md

# Third-party plugin cache — valid config, ignored:
~/.claude/plugins/cache/<marketplace>/verible-lsp/1.0.0/
├── .claude-plugin/
│   └── plugin.json      # includes lspServers field
├── .lsp.json             # valid LSP server definition
└── README.md

LSP tool result:

LSP documentSymbol on .sv file → "No LSP server available for file type: .sv"

Language server works correctly when tested directly via stdin:

{"id":1,"jsonrpc":"2.0","result":{"capabilities":{
  "codeActionProvider":true,
  "definitionProvider":true,
  "documentSymbolProvider":true,
  "referencesProvider":true,
  "renameProvider":true
}}}

This blocks all SystemVerilog/Verilog code intelligence in Claude Code. The plugin validates successfully, shows as enabled, but the LSP Manager never picks up its server definition.

dhollman contributor · 5 months ago

Hey everyone! Thanks for your patience on this! I put in what I hope is the final fix for this issue yesterday, and it should be in today's release (2.1.76). Please let us know if you're still seeing this in 2.1.76 or later!

github-actions[bot] · 5 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

LSP plugins not registering servers - LSP Manager initializes before plugins load

Bug Description

Environment

Steps to Reproduce

Expected Behavior

Actual Behavior

Debug Log Evidence

Plugin Configuration

Additional Context

Suggested Fix

8 Comments

Confirming on Linux + official marketplace plugin (v2.1.63)

Confirming for third-party marketplace plugin (verible-lsp) on Linux v2.1.63

Related Claude Code issues

Browse by topic