[BUG] LSP plugins not recognized - "No LSP server available" despite correct configuration

[coygeek]

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

LSP plugins configured following the official documentation are not recognized by Claude Code. The LSP tool returns "No LSP server available for file type: .py" and "No LSP server available for file type: .ts" despite:

1. Plugins being correctly structured with .lsp.json at the plugin root
2. Plugins registered in installed_plugins.json
3. Plugins enabled in settings.json
4. Language server binaries installed and in PATH
5. Multiple Claude Code restarts after configuration

This appears to be a fundamental issue where Claude Code's plugin system does not load or recognize LSP configurations from plugins.

What Should Happen?

When LSP plugins are correctly configured and enabled:

1. Claude Code should start the language servers on startup
2. The LSP tool should recognize file types and provide code intelligence
3. Operations like documentSymbol, hover, goToDefinition should work

Error Messages/Logs

**LSP Tool Output:**

No LSP server available for file type: .py
No LSP server available for file type: .ts


**No LSP-specific logs found in `~/.claude/debug/`** - there is no feedback about LSP server startup success/failure.

Steps to Reproduce

1. System Info

• Claude Code version: 2.0.74
• macOS Darwin 25.1.0
• typescript-language-server: 5.1.3 (/opt/homebrew/bin/typescript-language-server)
• pyright: 1.1.407 (/opt/homebrew/bin/pyright-langserver)

2. Create Plugin Directory Structure

~/.claude/plugins/cache/claude-plugins-official/
├── pyright-lsp/1.0.0/
│   ├── .claude-plugin/
│   │   └── plugin.json
│   ├── .lsp.json
│   └── README.md
└── typescript-lsp/1.0.0/
    ├── .claude-plugin/
    │   └── plugin.json
    ├── .lsp.json
    └── README.md

3. Plugin Configuration Files

pyright-lsp/1.0.0/.claude-plugin/plugin.json:

{
  "name": "pyright-lsp",
  "version": "1.0.0",
  "description": "Python language server (Pyright) for Claude Code",
  "lspServers": {
    "python": {
      "command": "pyright-langserver",
      "args": ["--stdio"],
      "extensionToLanguage": {
        ".py": "python",
        ".pyi": "python"
      }
    }
  }
}

pyright-lsp/1.0.0/.lsp.json:

{
  "pyright": {
    "command": "pyright-langserver",
    "args": ["--stdio"],
    "extensionToLanguage": {
      ".py": "python",
      ".pyi": "python"
    }
  }
}

typescript-lsp/1.0.0/.claude-plugin/plugin.json:

{
  "name": "typescript-lsp",
  "version": "1.0.0",
  "description": "TypeScript/JavaScript language server for Claude Code",
  "lspServers": {
    "typescript": {
      "command": "typescript-language-server",
      "args": ["--stdio"],
      "extensionToLanguage": {
        ".ts": "typescript",
        ".tsx": "typescriptreact",
        ".js": "javascript",
        ".jsx": "javascriptreact",
        ".mts": "typescript",
        ".cts": "typescript",
        ".mjs": "javascript",
        ".cjs": "javascript"
      }
    }
  }
}

typescript-lsp/1.0.0/.lsp.json:

{
  "typescript": {
    "command": "typescript-language-server",
    "args": ["--stdio"],
    "extensionToLanguage": {
      ".ts": "typescript",
      ".tsx": "typescriptreact",
      ".js": "javascript",
      ".jsx": "javascriptreact",
      ".mts": "typescript",
      ".cts": "typescript",
      ".mjs": "javascript",
      ".cjs": "javascript"
    }
  }
}

4. Register Plugins

~/.claude/plugins/installed_plugins.json:

{
  "version": 2,
  "plugins": {
    "pyright-lsp@claude-plugins-official": [
      {
        "scope": "user",
        "installPath": "/Users/user/.claude/plugins/cache/claude-plugins-official/pyright-lsp/1.0.0",
        "version": "1.0.0",
        "installedAt": "2025-12-19T23:00:16.582Z",
        "lastUpdated": "2025-12-19T23:00:16.582Z",
        "isLocal": true
      }
    ],
    "typescript-lsp@claude-plugins-official": [
      {
        "scope": "user",
        "installPath": "/Users/user/.claude/plugins/cache/claude-plugins-official/typescript-lsp/1.0.0",
        "version": "1.0.0",
        "installedAt": "2025-12-19T23:00:41.785Z",
        "lastUpdated": "2025-12-19T23:00:41.785Z",
        "isLocal": true
      }
    ]
  }
}

5. Enable Plugins

~/.claude/settings.json (relevant section):

{
  "enabledPlugins": {
    "pyright-lsp@claude-plugins-official": true,
    "typescript-lsp@claude-plugins-official": true
  }
}

6. Restart Claude Code and Test

# Restart Claude Code
claude

# Test LSP on a Python file
# LSP tool with operation: documentSymbol, filePath: /path/to/test.py
# Result: "No LSP server available for file type: .py"

# Test LSP on a TypeScript file
# LSP tool with operation: documentSymbol, filePath: /path/to/test.ts
# Result: "No LSP server available for file type: .ts"

Claude Model

None

Is this a regression?

I don't know

Last Working Version

2.0.74

Claude Code Version

2.0.74

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Community Workaround

The community has developed a workaround via the Piebald-AI/claude-code-lsps repository, which requires patching Claude Code using npx tweakcc --apply. The repository description states:

"LSP support in Claude Code is pretty raw still. There are bugs in the different LSP operations, no documentation, and no UI indication that your LSP servers are started/running/have errors or even exist."

This suggests the native LSP plugin loading mechanism has unresolved issues.

Missing Feedback

There is no indication in Claude Code about:

• Whether LSP plugins were detected
• Whether LSP servers started successfully
• Any errors during LSP server initialization

Running with --enable-lsp-logging produces no LSP-specific output.

Expected vs Actual Behavior

Expectation	Reality
Plugin system reads .lsp.json	No evidence of recognition
LSP servers start on startup	No servers started
LSP tool finds available servers	Returns "No LSP server available"
Debug logging shows LSP status	No LSP-related debug output

Requested Fix

1. Make the plugin system actually load and start LSP servers from .lsp.json configurations
2. Add logging/feedback when LSP servers start or fail to start
3. Document the correct plugin structure for LSP servers
4. Consider adding /lsp status command to show configured servers

[github-actions[bot]]

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/13952

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

[coygeek]

Follow-up: Found a potentially related issue that might explain this behavior.

#13952 reports a race condition where the LSP Manager initializes and completes with 0 servers before plugins have finished loading. Debug logs in that issue show:

08:57:37.373Z [DEBUG] LSP notification handlers registered successfully for all 0 server(s)
08:57:37.425Z [DEBUG] Loading plugin phpactor-lsp from source: "./phpactor-lsp"

The LSP Manager finishes 52ms before plugins load, so it never sees the LSP configurations.

That issue identifies this as a regression:

• Working: 2.0.67
• Broken: 2.0.69, 2.0.71, 2.0.72, 2.0.73, 2.0.74

This would explain why my configuration appears correct but LSP servers are never recognized. I haven't tested the 2.0.67 downgrade workaround yet, but if confirmed, this issue may be a duplicate of #13952.

[cgsergey]

Same issue here with Swift LSP (swift-lsp@claude-plugins-official).

• Installed via official plugin flow
• Enabled in settings
• sourcekit-lsp binary exists and is executable
• Swift index successfully built

Still returns: No LSP server available for file type: .swift

The race condition identified in #13952 (LSP Manager initializes before plugins load) appears to be the root cause.

[jeroendee]

Same issue with the gopls LSP installed.

• official plugin installed;
• gopls is installed;
• lsp marketplace present:

{
      "name": "gopls-lsp",
      "description": "Go language server for code intelligence and refactoring",
      "version": "1.0.0",
      "author": {
        "name": "Anthropic",
        "email": "[email protected]"
      },
      "source": "./plugins/gopls-lsp",
      "category": "development",
      "strict": false,
      "lspServers": {
        "gopls": {
          "command": "gopls",
          "extensionToLanguage": {
            ".go": "go"
          }
        }
      }
    }

example output in cc (when asking to demonstrate LSP functionalities...)

LSP(operation: "documentSymbol", file: "internal/renderer/renderer.go")
  ⎿  No LSP server available for file type: .go

[natepiano]

same issue for rust:

No LSP server available for file type: .rs

sure would be nice to have this working!

[ahicks92]

My case looks almost like a duplicate of this. I tried the Rust plugin. But in my case not only did it not seem to recognize LSPs, it didn't even make the LSP tool available. I was able to hack it via ENABLE_LSP_TOOL env var (undocumented) which got me as far as the tool, then hit this issue. rust-analyzer is on the path etc, in fact Claude successfully invoked it itself via the bash tool without issue as part of debugging the setup.

I am weakly assuming that in some case very similar to this Claude Code doesn't expose the LSP tool if there are no LSP servers, and that since there are no LSP servers, I don't even get the tool. But maybe that's not the case. I'll open another issue if this one doesn't resolve my problem.

[vnz]

Confirming this issue on v2.0.75 (Opus 4.5).

Affected LSP plugins (all installed from official marketplace):

• typescript-lsp
• pyright-lsp
• gopls-lsp
• rust-analyzer-lsp
• lua-lsp
• terraform-lsp (custom plugin from my own marketplace)

Behavior: All plugins show as "Installed" and "Enabled" in /plugin, but any LSP operation returns:

No LSP server available for file type: .tf
No LSP server available for file type: .ts

Environment:

• Linux (Debian 13)
• Claude Code v2.0.75
• ENABLE_LSP_TOOL=1 is set in settings.json

Workaround attempted: Created a custom terraform-lsp plugin/marketplace (vnz/terraform-lsp-claude-code) - same result. Plugin installs correctly but LSP never activates.

Would appreciate a fix or workaround. Happy to provide debug logs if needed.

[Manouchehri]

Same issue here.

[mateuszb]

same issue with clangd-lsp

[luffichen]

Same issue with gopls-lsp

[ferazambuja]

Same issue for swift-lsp

[coygeek]

Follow-up: LSP Plugin Race Condition Confirmed via Version Comparison

Related Issues: #14803, #13952

---

TL;DR

I've confirmed the race condition hypothesis from #13952. Version 2.0.67 works correctly; 2.0.76 is broken. The LSP Manager now completes initialization before plugins load, causing it to register 0 servers.

---

Investigation Methodology

Testing Multiple Versions Without Reinstalling

I discovered that npx allows running any Claude Code version without affecting the global installation:

# Current global installation remains untouched
claude --version  # 2.0.76

# Run old version via npx (downloads to cache, runs once)
npx @anthropic-ai/[email protected] --version  # 2.0.67

This approach:

• Doesn't overwrite the global npm installation
• Auto-caches packages in ~/.npm/_npx/
• Works with all Claude Code features
• Enables A/B testing between versions

Version Matrix Tested

Method	Version	LSP Status
Global npm	2.0.76	Broken (0 servers)
npx	2.0.67	Working (3 servers)

---

Debug Log Comparison

Capturing Debug Logs

Claude Code writes debug logs to ~/.claude/debug/<session-id>.txt. After running both versions, I compared the LSP/plugin initialization sequences.

# Find recent debug files
ls -lt ~/.claude/debug/*.txt | head -5

# Search for LSP/plugin timing
grep -i "lsp\|plugin\|manager" ~/.claude/debug/<session-id>.txt

Version 2.0.67 — WORKING

03:21:22.303Z [LSP MANAGER] initializeLspServerManager() called
03:21:22.303Z [LSP MANAGER] Created manager instance, state=pending
03:21:22.303Z [LSP MANAGER] Starting async initialization (generation 1)
03:21:22.303Z [LSP SERVER MANAGER] initialize() called
03:21:22.303Z [LSP SERVER MANAGER] Calling getAllLspServers()
03:21:22.308Z Loading plugin example-skills from source: "./"
...
03:21:22.329Z Loading plugin pyright-lsp from source: "./plugins/pyright-lsp"
03:21:22.331Z Loading plugin typescript-lsp from source: "./plugins/typescript-lsp"
03:21:22.332Z Found 3 plugins (2 enabled, 1 disabled)
...
03:21:22.488Z Loaded 2 LSP server(s) from plugin: pyright-lsp
03:21:22.489Z Loaded 1 LSP server(s) from plugin: typescript-lsp
03:21:22.489Z Total LSP servers loaded: 3
03:21:22.489Z [LSP SERVER MANAGER] getAllLspServers returned 3 server(s)
03:21:22.489Z Starting LSP server instance: plugin:pyright-lsp:pyright
03:21:22.491Z Starting LSP server instance: plugin:pyright-lsp:python
03:21:22.492Z Starting LSP server instance: plugin:typescript-lsp:typescript

Key observation: getAllLspServers() blocks and waits for plugins to load, then returns 3 servers.

Version 2.0.76 — BROKEN

03:19:54.704Z [LSP MANAGER] initializeLspServerManager() called
03:19:54.704Z [LSP MANAGER] Created manager instance, state=pending
03:19:54.704Z [LSP MANAGER] Starting async initialization (generation 1)
03:19:54.709Z LSP server manager initialized successfully
03:19:54.709Z LSP notification handlers registered successfully for all 0 server(s)
03:19:54.710Z Loading plugin example-skills from source: "./"
...
03:19:54.729Z Loading plugin pyright-lsp from source: "./plugins/pyright-lsp"
03:19:54.730Z Loading plugin typescript-lsp from source: "./plugins/typescript-lsp"
03:19:54.731Z Found 3 plugins (2 enabled, 1 disabled)

Key observation: LSP Manager completes with 0 servers at 03:19:54.709Z, then plugins start loading at 03:19:54.710Z — 1ms too late.

---

Root Cause Analysis

The Race Condition

Event	v2.0.67	v2.0.76
LSP Manager init starts	T+0ms	T+0ms
getAllLspServers() called	T+0ms	—
Plugins load	T+5ms	T+6ms
LSP servers registered	T+186ms	Never
LSP Manager completes	T+186ms (3 servers)	T+5ms (0 servers)

What Changed

Between 2.0.67 and 2.0.69+, the LSP Manager initialization was refactored to be async and non-blocking. This appears to be a performance optimization that inadvertently broke the dependency chain:

Before (2.0.67):

initLspManager() → getAllLspServers() → [waits for plugins] → register servers

After (2.0.76):

initLspManager() → complete immediately with 0 servers
                   ↓
            (plugins load later, servers never registered)

Why This Wasn't Caught

1. No integration tests for LSP + plugins initialization order
2. LSP feature likely tested with hardcoded/mock servers, not plugin-loaded servers
3. Debug logs didn't exist in earlier versions to catch the timing issue
4. Silent failure — no error messages, just "No LSP server available"

---

Verification Steps

Anyone can reproduce this:

# 1. Ensure LSP plugins are configured per the original issue

# 2. Test with broken version
claude --version  # Should show 2.0.69+
claude -p "Use LSP documentSymbol on test.py"
# Result: "No LSP server available for file type: .py"

# 3. Test with working version
npx @anthropic-ai/[email protected] -p "Use LSP documentSymbol on test.py"
# Result: Returns actual symbols from pyright

# 4. Compare debug logs
diff <(grep "LSP" ~/.claude/debug/<broken-session>.txt) \
     <(grep "LSP" ~/.claude/debug/<working-session>.txt)

---

Recommended Fixes

Option 1: Restore Blocking Behavior (Quick Fix)

Revert initializeLspServerManager() to block until getAllLspServers() completes, which in turn waits for plugins to load.

// Pseudo-fix
async function initializeLspServerManager() {
  await loadAllPlugins();  // Ensure plugins load first
  const servers = getAllLspServers();
  registerNotificationHandlers(servers);
}

Option 2: Lazy Server Registration (Better)

Keep async init but register servers lazily when first requested:

async function getLspServerForFile(filePath: string) {
  if (!this.serversInitialized) {
    await this.waitForPlugins();
    this.servers = getAllLspServers();
    this.serversInitialized = true;
  }
  return this.servers.find(s => s.handles(filePath));
}

Option 3: Event-Driven Registration (Best)

Plugins emit an event when LSP servers are available; LSP Manager subscribes:

pluginSystem.on('lspServersAvailable', (servers) => {
  this.registerServers(servers);
});

---

Workarounds for Users

Workaround 1: Pin to 2.0.67

npm install -g @anthropic-ai/[email protected]

Downside: Miss out on new features and fixes.

Workaround 2: Use npx Aliases

Add to ~/.zshrc or ~/.bashrc:

alias claude-lsp='npx @anthropic-ai/[email protected]'

Use claude-lsp when you need LSP functionality.

Workaround 3: Community Patch

The Piebald-AI/claude-code-lsps repo patches the initialization order:

npx tweakcc --apply

---

Summary

Finding	Detail
Confirmed regression	2.0.67 → 2.0.69+
Root cause	Async LSP Manager init completes before plugins load
Evidence	Debug logs show 0 servers registered, plugins load 1ms later
Affected versions	2.0.69, 2.0.71, 2.0.72, 2.0.73, 2.0.74, 2.0.75, 2.0.76
Last working version	2.0.67
Workaround	npx @anthropic-ai/[email protected]

This confirms #13952 and should likely be marked as a duplicate. The fix should prioritize restoring the initialization order dependency.

---

Test Environment:

• macOS Darwin 25.1.0
• Claude Code 2.0.76 (broken) / 2.0.67 (working)
• Plugins: [email protected], [email protected]
• Language servers: pyright-langserver 1.1.407, typescript-language-server 5.1.3

[simasch]

Savme issue with Java

LSP(operation: "findReferences", file: "src/main/java/app/voluntarix/event/domain/EventRepository.java", position: 37:20) ⎿  No LSP server available for file type: .java

[andre-wstudio]

Really?

[sdelicata]

As mentioned multiple times, downgrading to 2.0.67 works fine.

[timurkhakhalev]

Same issue on 2.0.76 with typescript lsp server

[ravshansbox]

This is working on 2.0.73 as well

[bcherny]

Fix incoming

[abicorios]

@ravshansbox, no, it is some confused mix. It was just the Search tool, because the LSP tool was disabled for the Claude Code. The LSP must looks, for example LSP(operation: "documentSymbol", file: "hello.js"). You can compare:

npm install -g typescript-language-server typescript
echo 'export ENABLE_LSP_TOOL=1' >> ~/.bashrc
npx @anthropic-ai/[email protected]
/plugin install typescript-lsp@claude-plugins-official
/exit
npx @anthropic-ai/[email protected]
> lsp search in hello.js 

● LSP(operation: "documentSymbol", file: "hello.js")
  ⎿  Found 2 symbols (ctrl+o to expand)

● Found 2 symbols in hello.js:

  | Symbol  | Type     | Line |
  |---------|----------|------|
  | greet   | Function | 1    |
  | message | Constant | 5    |

[ytzhakov]

got the same issue , version 2.0.76

[MarjovanLier]

@bcherny , when will the fix be released?

[dlprentice]

@bcherny not working on 2.0.76 (windows) - haven't tried wsl