[BUG] LSP servers not loading due to race condition between LSP Manager initialization and plugin loading

Confirming this is still present in 2.0.71.

Platform: Linux (Arch, 6.17.9-arch1-1)
Terminal: tmux

Debug log shows same pattern:

14:10:55.958Z [DEBUG] [LSP MANAGER] Starting async initialization (generation 1)
14:10:55.959Z [DEBUG] LSP notification handlers registered successfully for all 0 server(s)
14:10:55.968Z [DEBUG] Loading plugin lsp from source: "./lsp"

Plugin loads correctly, lspServers config is valid, but LSP manager has already completed initialization 10ms earlier.

Confirmed on 2.0.72

Platform: macOS Darwin 24.3.0
Working version: 2.0.67 ✓
Broken version: 2.0.72 ✗

Debug log (2.0.72)

14:30:15.580Z [DEBUG] LSP notification handlers registered successfully for all 0 server(s)
14:30:15.596Z [DEBUG] Loading plugin pyright-lsp from source: "./plugins/pyright-lsp"

16ms gap - LSP Manager completes before plugins load.

Verification

Tested pyright-lsp@claude-plugins-official plugin with ENABLE_LSP_TOOL=true:

| Version | LSP Tool | Pyright Diagnostics |
|---------|----------|---------------------|
| 2.0.67 | ✓ Available | ✓ 3 errors detected |
| 2.0.72 | ✓ Available | ✗ "No LSP server available for .py" |

The LSP tool exists in 2.0.72, but no servers are registered due to the race condition.

Workaround

npx @anthropic-ai/claude-code@2.0.67 works as temporary solution.

Follow-up: Also confirmed broken in 2.0.73 (same behavior - LSP tool exists but 'No LSP server available for file type: .py').

Confirming it's still happening on 2.0.74 as well.

Seems they just released LSPs officially.

• https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
• https://code.claude.com/docs/en/plugins-reference#lsp-servers
• https://code.claude.com/docs/en/plugins#add-lsp-servers-to-your-plugin

However, the race condition persists. Anyone else get it working?

Additional testing evidence from 2.0.74 (comment drafted by Claude Code, posted on behalf of Marjo)

Extensive testing confirms the race condition persists in 2.0.74, including with official Anthropic LSP plugins:

Official plugins tested:

• php-lsp@claude-plugins-official - same race condition
• pyright-lsp@claude-plugins-official - same race condition

2.0.74 race gap measurements:

00:42:03.401Z - [LSP MANAGER] initializeLspServerManager() called
00:42:03.405Z - LSP handlers registered for 0 server(s)
00:42:03.463Z - phpactor-lsp loads (58ms LATE)
00:42:03.466Z - php-lsp loads (61ms LATE)
00:42:04.132Z - pyright-lsp loads (727ms LATE)

New in 2.0.74: LSP Plugin Recommendation feature correctly detects installed plugins but servers still don't register:

[lspRecommendation] Skipping php-lsp@claude-plugins-official (already installed)
LSP Diagnostics: Checking registry - 0 pending

Configuration changes have no effect - tested with startupTimeout, maxRestarts, restartOnCrash, and loggingConfig options. The .lsp.json files are never read due to the race condition.

Confirmed broken versions: 2.0.69, 2.0.72, 2.0.73, 2.0.74
Last working version: 2.0.67

Can confirm, it's broken in 2.0.74, works in 2.0.67

They added it as an official release note today and still broken lol.

just confirming, broken here on 2.0.74

cat ~/.claude/debug/latest | grep -i lsp | head -n 7

2025-12-20T12:48:55.961Z [DEBUG] [LSP MANAGER] initializeLspServerManager() called
2025-12-20T12:48:55.961Z [DEBUG] [LSP MANAGER] Created manager instance, state=pending
2025-12-20T12:48:55.961Z [DEBUG] [LSP MANAGER] Starting async initialization (generation 1)
2025-12-20T12:48:55.964Z [DEBUG] LSP server manager initialized successfully
2025-12-20T12:48:55.964Z [DEBUG] LSP notification handlers registered successfully for all 0 server(s)
2025-12-20T12:48:55.967Z [DEBUG] Loading plugin rust-analyzer-lsp from source: "./plugins/rust-analyzer-lsp"
2025-12-20T12:48:55.967Z [DEBUG] Using provided version for rust-analyzer-lsp@claude-plugins-official: 1.0.0

claude --version:

2.0.74 (Claude Code)

Found the issue. The LSP server manager's initialize function is essentially empty, it just returns immediately without doing anything. There's a separate function that properly loads LSP server configurations from enabled plugins, but this function is never called anywhere in the codebase.

2.0.75 was released, still has the issue.

why do the release notes announce the LSP function as being released if it is not working?

...
Version 2.0.74:
• Added LSP (Language Server Protocol) tool for code intelligence features like go-to-definition, find references, and hover documentation
...

No LSP server available for file type .tsx
same issue!

Same issue on v2.0.75 for me.

Same issue with Go LSP (gopls) on v2.0.75

Same issue.

same issue here, wonder if there anything we can do locally to make it work

@giovannirco as described in the second reply:

npx @anthropic-ai/claude-code@2.0.67 works as temporary solution.

I actually haven't done this, I'm just waiting - but it should work. Depending on how you installed you may need to do something slightly different? The key is pinning the version at 2.0.67.

Race Condition Confirmed:
https://github.com/anthropics/claude-code/issues/14803#issuecomment-3684942251

Not working on 2.0.76 either, race condition persists.

so i dove into the problem and found that this is not a race condition, it's simply not implemented afaict (at least in 2.0.74, which is what's latest in nixpkgs), the function supposedly responsible for registering the LSPs simply returns for no good reason I can find.
I made a patch for this against 2.0.74, but with some tweaks it should be possible to port this to other versions, the problem is that the minified function name may change.
But hopefully this gives people some idea of what to do about it instead of shouting into the void and hoping someone will actually care that the newly announced feature doesn't actually work at all...

claude-code-2.0.74-lsp-not-found-fix.patch

also, i just have to say i find it silly that they release minified code, this stuff doesn't have to run in the browser, so what's the point other than to annoy people and make community contributions harder.

Thanks for the insights @manveru, I wonder what happened internally that the actual code was not released with the release.

Same for .cs

No LSP server available for file type: .cs

Workaround: Install Patched Claude Code 2.0.74 with LSP Fix

Thanks to @manveru for creating this patch!

This workaround installs Claude Code 2.0.74 to a separate directory (leaving your main installation untouched) and applies a patch that fixes the LSP race condition.

Steps

1. Download the patch file

curl -L -o ~/Downloads/claude-code-2.0.74-lsp-not-found-fix.patch \
  "https://github.com/user-attachments/files/24315782/claude-code-2.0.74-lsp-not-found-fix.patch"

2. Install Claude Code 2.0.74 to a dedicated directory

mkdir -p ~/.claude-lsp
cd ~/.claude-lsp
echo '{"name": "claude-lsp-patched", "version": "1.0.0"}' > package.json
npm install @anthropic-ai/claude-code@2.0.74

3. Apply the patch

cd ~/.claude-lsp/node_modules/@anthropic-ai/claude-code
patch -p1 < ~/Downloads/claude-code-2.0.74-lsp-not-found-fix.patch

4. Add an alias to your shell config

For zsh (~/.zshrc):

echo "alias claude-patched='node ~/.claude-lsp/node_modules/@anthropic-ai/claude-code/cli.js'" >> ~/.zshrc
source ~/.zshrc

For bash (~/.bashrc):

echo "alias claude-patched='node ~/.claude-lsp/node_modules/@anthropic-ai/claude-code/cli.js'" >> ~/.bashrc
source ~/.bashrc

5. Run the patched version

claude-patched

Notes

• Your system's main Claude Code installation remains untouched
• You can switch between claude (system) and claude-patched (with LSP fix) as needed
• Make sure you have an LSP plugin installed (e.g., rust-analyzer-lsp from the official marketplace)

Verification

After starting claude-patched, LSP features should work without the "No LSP server available" error.

<img width="772" height="254" alt="Image" src="https://github.com/user-attachments/assets/e44594a8-a9b5-4e63-8225-1531f88fe85a" />

got the same issue, version 2.0.76

Fix incoming
https://github.com/anthropics/claude-code/issues/14803#issuecomment-3690488192

Fix incoming #14803 (comment)

I see the fix was a day ago, wonder when we'll get it.

while we wait for the proper fix, claude and i got this script working to patch 2.0.76 and fix the lsp feature. it seems to be working for me, but YMMV

also, i just have to say i find it silly that they release minified code, this stuff doesn't have to run in the browser, so what's the point other than to annoy people and make community contributions harder.

I really wish they would open source Claude Code entirely. They want to limit the "access" of the agents to their services, but they're basically just fragmenting the efforts of the community. I personally think they'd do BETTER if they OSSed the project and would likely see larger numbers of subscriptions as a result.

OpenCode is a cool project, but it almost certainly wouldn't exist if Claude Code decided to go OSS. I'm not holding my breath though...

Maybe today we get a new version? It would be super if @bcherny and the team could make it possible.

Confirmation: Bug persists in Claude Code 2.0.76 on Windows

I can confirm this race condition bug still exists in the latest version. Here's my detailed debugging session:

Environment

• OS: Windows 11
• Shell: PowerShell 7.5.4 (pwsh)
• Claude Code: 2.0.76 (both native binary and npm installation)
• Python: 3.10.16 (Anaconda)
• Pyright: 1.1.396

Setup Steps Taken

1. Set environment variable:

``powershell
$env:ENABLE_LSP_TOOLS = "1"
``

1. Installed pyright language server:

``bash
pip install pyright
# Verified: G:\programy\anaconda3\envs\predikceRRR\Scripts\pyright.exe --version
# pyright 1.1.396
``

1. Installed official plugin:

``bash
claude plugin install pyright-lsp --scope user
# Successfully installed: pyright-lsp@claude-plugins-official
``

1. Verified plugin is enabled:

``json
// ~/.claude/settings.json
{
"enabledPlugins": {
"pyright-lsp@claude-plugins-official": true
}
}
``

Debug Log Evidence

From ~/.claude/debug/latest (timestamp 2025-12-29):

15:12:13.373Z [DEBUG] [LSP MANAGER] initializeLspServerManager() called
15:12:13.373Z [DEBUG] LSP notification handlers registered successfully for all 0 server(s)
...
15:12:13.447Z [DEBUG] Loaded plugin pyright-lsp from cache successfully
15:12:13.452Z [DEBUG] Starting LSP server: pyright

Key observation: LSP Manager initializes at .373Z with 0 servers, then plugins load at .447Z (74ms later). The LSP server config from the plugin is never picked up.

Additional Workarounds Attempted (All Failed)

1. Piebald-AI community marketplace:

``bash
claude plugin marketplace add https://github.com/Piebald-AI/claude-code-lsps.git
claude plugin install pyright@claude-code-lsps --scope user
``
Result: Same 0 servers issue.

1. tweakcc community patch (v3.2.2):

``bash
npm install -g @anthropic-ai/claude-code
npx tweakcc install
# Claude Code v2.0.76 + tweakcc v3.2.2
``
Result: tweakcc applies visual/UI patches but does not fix the LSP race condition. Still shows 0 servers in debug log.

1. npm installation instead of native binary:

Same race condition persists regardless of installation method.

Impact

LSP features (goToDefinition, findReferences, hover, diagnostics) are completely non-functional. The lsp tool is not available even when:

• ENABLE_LSP_TOOLS=1 is correctly set
• Plugin is installed and enabled
• Language server binary is in PATH and working

Suggested Fix

The LSP Manager initialization should wait for plugin loading to complete, or there should be a mechanism to re-scan for LSP configs after plugins are loaded. The current sequence needs to be:

1. Load plugins (including LSP configs)
2. Initialize LSP Manager (now sees plugin configs)
3. Register LSP servers

Instead of current broken sequence:

1. Initialize LSP Manager (0 servers)
2. Load plugins (too late, configs ignored)

Version Regression Confirmation

Per original report, this worked in 2.0.67. I can confirm it's broken in:

• 2.0.75
• 2.0.76
• 2.0.76 + tweakcc v3.2.2

Confirmed in v2.0.76 with custom plugin.

I can reproduce this race condition with a plugin containing .lsp.json for clangd (C++ LSP server). Debug logs show:

20:35:31.175Z LSP notification handlers registered for all 0 server(s)
20:35:31.175Z Found 0 plugins (0 enabled, 0 disabled)

Additional finding: Placing .lsp.json directly in workspace root also fails - Claude Code only reads .lsp.json from plugin directories, which load after LSP Manager initialization.

Workarounds attempted:

• ❌ Workspace-level .lsp.json - not supported
• ❌ Plugin .lsp.json - race condition
• ❌ Official marketplace plugins - affected per other reports

The only solution is building a custom MCP server wrapping the language server, which defeats the purpose of LSP plugin support.

Request: Could we get an official Anthropic response on timeline for a fix? Thank you!!

Confirmed in v2.0.76. Please fix.
UPDATE:
Currently using this unofficial patch and it works: https://gist.github.com/Zamua/f7ca58ce5dd9ba61279ea195a01b190c

Does not work for me on 2.0.76 either for typescript from the official plugin. It was working before

Has anyone used claude code to fix this? can download it here: https://claude.ai/code

Does this feature work for ANYONE? I imagine it must, or else Anthropic would be prioritizing a fix more highly...

@aivajoe, it doesn't work yet, but an official fix is on the way. The last update I saw was that the team is on leave.

Can confirm that its not working for version 2.0.76

on macOS too not working

A lot of "me too!" comments here... If you are here to post that, consider clicking a reaction emoji to the original comment and/or subscribing to this issue instead.

Side question: Is there any opportunity here for a community member to open a PR fixing the issue, or is the code responsible for this not open source in this project?

@noahlz none of Claude Code is open source. This repo doesn't actually contain any code

New version go release https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

What makes us think this new version fixes this particular issue...?

EDIT: the latest version I see in the CHANGELOG.md is 2.0.76, which doesn't look related. Maybe something weird is going on.

Latest changelog (v2.1.0) shows these LSP related fixes:

1. Fixed LSP tool being incorrectly enabled when no LSP servers were configured
2. Fixed race condition where LSP tool could return "no server available" during startup

Was LSP removed in 2.1.1?

I now see LSP working in 2.1.1 👍

Works now.

Here's a gist I created about how to setup, verify, etc.

@coygeek thank you for sharing!

i did test the pyright LSP, but still not work for me. Maybe i did something wrong?
env:

• windows 11 with gitbash
• have python project with virtual env in .venv folder

what i did to test

1. installed pyright globally with npm
2. enabled pyright lsp plugin
3. start claude code with virtual env activated
4. prompt: "use lsp to check {somepythonfile}.py

but there are no symbols, can't resolve the import from project subfolder, no hover info

try to fix:
added pyrightconfig.json file in project root folder with the content

{
  "include": [
    "."
  ],
  "venvPath": {{windows absolution path to project with windows style path}},
  "venv": ".venv",
  "reportMissingImports": "error",
  "reportMissingTypeStubs": "information",
  "reportUnusedVariable": "information",
  "reportUnusedImport": "warning",
  "reportUnusedFunction": "information",
  "reportUnusedClass": "information",
  "exclude": [
    "**/__pycache__/**",
    "**/*.pyc",
    "**/*.pyo",
    ".claude",
    ".serena",
    ".pytest_cache",
    "logs",
    "data",
    "jobs",
    "docs",
    "scripts",
    "tmp"
  ]

But didn't help, still nothing

and one observation:
start the claude code, the pyright_langserver.exe from system python (not from npm)/Scripts folder will be started
and if i start git bash and which pyright_langserver, the npm path is displayed

what i did wrong? could someone share the functional setup for python project?

Thank you very much!

BR

I'm having issues as well. When I install a plugin all I see in the folder is a README folder which essentially gives a one sentence desription like "C# language server for Claude Code, providing code intelligence and diagnostics." and how to install, there's nothing else there.

I installed the LSP as per the README, and when I launch claude I see the LSP launch and is running in my task manager but when I ask Claude about it he just says he has no access to LSP.

I'm on Claude 2.1.1 using Windows 10. Happy to provide any info that will help solve it just let me know.

Try this @jixian01 and @RasZCode
https://pastebin.com/ALtQGUTQ

Windows Workaround: LSP Integration via cclsp + cmd /c wrapper

Disclaimer: This is a community workaround I found after hours of troubleshooting. It works on my setup but your mileage may vary. Use at your own risk - I take no responsibility for any issues that may arise from following this guide.

Environment

• OS: Windows 11
• IDE: VS Code with Claude Code extension
• Claude Code: 2.1.1
• Node.js: v22.16.0

Problem Summary

On Windows, the official LSP plugins (pyright-lsp, typescript-lsp) fail due to a race condition where the LSP Manager initializes before plugins finish loading. Additionally, alternative solutions like cclsp fail with spawn ENOENT errors because Node.js child_process.spawn() doesn't automatically resolve .cmd extensions on Windows.

Root Cause Analysis

When npm installs global packages on Windows, it creates two files:

• typescript-language-server (bash script for Unix)
• typescript-language-server.cmd (batch file for Windows)

Node.js spawn() without shell: true looks for an exact executable match. It finds the bash script (which it can't execute natively) instead of the .cmd file, resulting in ENOENT errors.

Working Solution

Use cclsp as an MCP server with cmd /c wrapper in the LSP commands. This forces Windows Command Prompt to resolve the .cmd binaries correctly.

Step-by-step Setup

1. Install dependencies globally:

npm install -g cclsp typescript-language-server typescript pyright

2. Create cclsp configuration file at ~/.config/claude/cclsp.json:

{
  "servers": [
    {
      "extensions": ["js", "ts", "jsx", "tsx", "mjs", "cjs"],
      "command": ["cmd", "/c", "typescript-language-server", "--stdio"],
      "rootDir": "."
    },
    {
      "extensions": ["py", "pyi"],
      "command": ["cmd", "/c", "pyright-langserver", "--stdio"],
      "rootDir": "."
    }
  ]
}

3. Register cclsp as MCP server in Claude Code:

claude mcp add cclsp cclsp

Then manually edit ~/.claude.json to add the environment variable. Find the cclsp entry under your project's mcpServers and ensure it looks like:

"cclsp": {
  "type": "stdio",
  "command": "cclsp",
  "args": [],
  "env": {
    "CCLSP_CONFIG_PATH": "C:\\Users\\<YOUR_USERNAME>\\.config\\claude\\cclsp.json"
  }
}

4. Reload Claude Code (Ctrl+Shift+P → Developer: Reload Window)

Verification

After reload, these LSP tools should be available:

• find_definition - Go to symbol definition
• find_references - Find all references across workspace
• rename_symbol - Safe cross-file refactoring
• get_diagnostics - Real-time errors and warnings

---

For Anthropic: Suggested Fix

The core issue is that spawn() on Windows needs either:

1. shell: true option, or
2. Explicit .cmd extension handling, or
3. Use of cross-spawn package which handles this automatically

This affects any plugin that spawns npm-installed binaries on Windows.

---

One-Click Setup for Claude Code Users

Copy this prompt and give it to Claude Code to automate the entire setup:

Set up LSP integration for Claude Code on Windows using cclsp. Steps to execute: 1. Run: npm install -g cclsp typescript-language-server typescript pyright 2. Create directory if needed: mkdir -p ~/.config/claude 3. Create file ~/.config/claude/cclsp.json with TypeScript and Python server configs using cmd /c wrapper 4. Run: claude mcp add cclsp cclsp 5. Edit ~/.claude.json to add env variable CCLSP_CONFIG_PATH pointing to the cclsp.json file 6. Tell me to reload Claude Code when done

---

Tested & Confirmed Working

All LSP features functional:

• ✅ get_diagnostics - Returns file errors/warnings
• ✅ find_definition - Navigates to symbol definitions
• ✅ find_references - Finds all usages across codebase
• ✅ rename_symbol - Performs safe cross-file renames

Hope this helps other Windows users until the official fix lands!

---

Alternative Approach: Local Plugin Override

For users who need project-specific LSP configurations (e.g., custom Python venv paths per project), see the local plugin override method described earlier in this thread.

| Approach | Best for |
|----------|----------|
| cclsp (this guide) | Global setup, works across all projects |
| Local plugins | Project-specific paths, custom venv configs |

Both use the same cmd /c workaround under the hood.

---

Written in collaboration with Claude Code

Alternative: pylsp instead of pyright-langserver

@samuelgudi's solution works great! Just wanted to add an alternative for those who still experience timeouts on documentSymbol requests with pyright-langserver.

Our Issue

With pyright-langserver, we had:

• get_diagnostics ✅ worked
• find_definition ❌ timeout 45s
• find_references ❌ timeout 45s

Solution: Switch to pylsp

pip install python-lsp-server

Then in cclsp.json, use pylsp instead of pyright-langserver:

{
  "servers": [
    {
      "extensions": ["py", "pyi"],
      "command": ["cmd", "/c", "pylsp"],
      "rootDir": "."
    }
  ]
}

Result

After restart + warm-up (30-60s for indexing), all tools work:

• get_diagnostics ✅
• find_definition ✅
• find_references ✅

When to try this

If you followed samuelgudi's guide but still get timeouts on find_definition/find_references, try switching from pyright-langserver to pylsp.

Full documentation: https://gist.github.com/stanicio/7b64a1f7f947b4d8f87d774e5baae0c0

Try this @jixian01 and @RasZCode https://pastebin.com/ALtQGUTQ

Thanks for replying @coygeek unfortunately the pastebin seems to no longer exist.

I started looking at the solution by samuelgudi but cclsp uses Omnisharp for C# which isn't the same server as in the Claude readme so I haven't pursued it any further for now.

Hopefully they get an official fix sorted.

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.