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

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

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.

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.

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": "support@anthropic.com"
      },
      "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

same issue for rust:

No LSP server available for file type: .rs

sure would be nice to have this working!

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.

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.

Same issue here.

same issue with clangd-lsp

Same issue with gopls-lsp

Same issue for swift-lsp

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/claude-code@2.0.67 --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/claude-code@2.0.67 -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/claude-code@2.0.67

Downside: Miss out on new features and fixes.

Workaround 2: Use npx Aliases

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

alias claude-lsp='npx @anthropic-ai/claude-code@2.0.67'

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/claude-code@2.0.67 |

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: pyright-lsp@1.0.0, typescript-lsp@1.0.0
• Language servers: pyright-langserver 1.1.407, typescript-language-server 5.1.3

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

Really?

As mentioned multiple times, downgrading to 2.0.67 works fine.

Same issue on 2.0.76 with typescript lsp server

This is working on 2.0.73 as well

<img width="1263" height="1062" alt="Image" src="https://github.com/user-attachments/assets/7de3111e-96cb-4d1a-93fb-9a25842de867" />

Fix incoming

@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/claude-code@2.0.67
/plugin install typescript-lsp@claude-plugins-official
/exit
npx @anthropic-ai/claude-code@2.0.67
> 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    |

got the same issue , version 2.0.76

@bcherny , when will the fix be released?

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

Same on Ubuntu 22.04 and vs code cli and extention

The last release of the cli was released 3 days ago, how this feature is supposed to be available you think?

Also do note that the example comment above by abicorios showing it working is using that undocumented env var (well undocumented as far as I know).

Claude Code v2.0.76 still can't work lsp searching

i'm also still experiencing this issue; it doesn't appear to be fixed

❯ claude --version
2.0.76 (Claude Code)
...

⏺ LSP(operation: "documentSymbol", file: "test-lsp.c")
  ⎿  No LSP server available for file type: .c

⏺ LSP(operation: "hover", symbol: "greetUser", in: "test-lsp.c")
  ⎿  No LSP server available for file type: .c

⏺ Neither works. Let me verify the LSP binaries are installed:

⏺ Bash(which clangd && clangd --version)
  ⎿  /usr/bin/clangd
     Apple clangd version 17.0.0 (clang-1700.0.13.5)
     Features: mac+xpc
     Platform: arm64-apple-darwin24.4.0
                                                                                                                                                            ⏺ Both clangd and typescript-language-server are installed, and the plugins are enabled, but neither LSP works.

1) "Me too" does not contribute to a solution
2) Think a bit about subscribed users before posting, do not be an a$$h0le

apologies; you're right. i didn't mean to disrupt

i did spend some more time with claude to see if i could get it patched for 2.0.76 (same as the person earlier in the thread got it working for 2.0.74), and i think i got a working script. running this script fixes lsps for me. i hope it works for others, or helps in any debugging, but apologies if it's just more noise 😓

Thanks, I can finally run the LSP now.

@Zamua — Thanks for that patch. Commenting so that others know they should try it too.
(Actually, CC applied it for me using a perl script it created, but it discovered how to fix using your script.)

Why is this closed? It is still not working out of box. Script is not fixing this bug for native installation.

Script is not fixing this bug for native installation

@msokolnickiitt are you referring to the script i made to patch cc? if so, can you comment on the gist with your script output and claude version and path and other details you think may be important, and i can help you debug further over there?

Still broken in 2.0.76 - Elixir LSP case with debug log evidence

Environment:

• Claude Code: 2.0.76
• macOS Darwin 25.2.0 (arm64)
• Node: 22.14.0 (via asdf)
• ENABLE_LSP_TOOL=1 set in environment

Plugin:

• elixir-lsp@claude-code-elixir v1.0.0 (from georgeguimaraes/claude-code-elixir)
• elixir-ls v0.30.0 installed at /usr/local/bin/elixir-ls and working (verified via direct execution)

Plugin config (correctly structured):

{
  "name": "elixir-lsp",
  "version": "1.0.0",
  "lspServers": {
    "elixir-ls": {
      "command": "elixir-ls",
      "args": [],
      "extensionToLanguage": {
        ".ex": "elixir",
        ".exs": "elixir",
        ".heex": "heex",
        ".leex": "leex"
      }
    }
  }
}

Debug log (~/.claude/debug/latest) shows plugin loads but NO LSP registration:

2025-12-30T20:10:30.058Z [DEBUG] Loading plugin elixir-lsp from source: "./plugins/elixir-lsp"
2025-12-30T20:10:30.059Z [DEBUG] Using manifest version for elixir-lsp@claude-code-elixir: 1.0.0
2025-12-30T20:10:30.059Z [DEBUG] Plugin elixir-lsp@claude-code-elixir version 1.0.0 already cached
2025-12-30T20:10:30.059Z [DEBUG] Copied local plugin elixir-lsp to versioned cache

What's missing: No subsequent log entries for:

• "LSP notification handlers registered"
• "Starting LSP server instance"
• "Loaded X LSP server(s) from plugin"

Result:

LSP(operation: "hover", file: "billing.ex", line: 40, character: 7)
⎿ No LSP server available for file type: .ex

---

Note on typescript-lsp@claude-plugins-official: This plugin only contains a README.md with installation instructions - it has no lspServers configuration in plugin.json, so it's not a functional LSP plugin.

The race condition identified in the earlier detailed analysis by @coygeek is confirmed - plugins load but LSP servers are never registered because LSP Manager completes before plugins finish loading.

Waiting for the fix mentioned by @bcherny - is there an ETA or a tracking PR?

Update on Zamua's patch for v2.0.76:

I tested the patch from @Zamua's gist (https://gist.github.com/Zamua/fd91ca5e05eac8a2efeeb15d8ac44f30) on v2.0.76 and it doesn't work.

Why the patch fails:

• The patch targets a specific pattern: async function G(){return}async function Z()
• In v2.0.76, there are 4 different async function G(){} functions in the minified code
• The patch replaced one in a CSS XSS filter library (completely unrelated to LSP)
• The actual LSP manager code uses different minified names (_P, jk, i52, etc.)

Debug log after "patched" restart still shows:

19:36:17.363Z [LSP MANAGER] initializeLspServerManager() called
19:36:17.378Z LSP notification handlers registered successfully for all 0 server(s)
19:36:17.436Z Loading plugin elixir-lsp...  <-- plugins load 58ms AFTER LSP manager finishes

Conclusion:
The minified function names change between versions, making patches unreliable. The race condition fix needs to come from an official release. Any ETA on the fix mentioned by @bcherny on Dec 24?

Chill out, its the holidays. Jesus Christ.

@mkreyman do you mind trying out the latest version of the gist? it's updated to parse the AST (no longer committing the sin of parsing a context-free grammar with regex lol), so hopefully now more resilient to minute differences in the minified js. if you have issues with it, please comment on the gist, and i can iterate with you there

> Script is not fixing this bug for native installation @msokolnickiitt are you referring to the script i made to patch cc? if so, can you comment on the gist with your script output and claude version and path and other details you think may be important, and i can help you debug further over there?

Hi, I have native version:
Diagnostics
└ Currently running: native (2.0.76)

so this file: cli.js not exist

I see there are several other issues related to this problem, like the one mentioned in your fix (https://github.com/anthropics/claude-code/issues/13952
), so maybe it will be fixed eventually. It’s not critical, but it sounds promising. 🙂

@msokolnickiitt please comment on the gist and i can help further 🙏

@Zamua big thanks for the script! Wasted so much time trying to get LSP working. I wish I found this earlier.

Something a few might run into when trying to run the patch. I previously installed claude-code with bun so the gist wasnt working for me to start with. Just something to keep in mind while we wait for an official fix.

same issue and the downgrade didnt work well to me
win11

I am facing same issue with Windows 11.

| Claude Code version | ✅ 2.0.76 (>= 2.0.74 required) |
| Plugins installed | ✅ omnisharp + vtsls |
| Plugins enabled | ✅ In settings.json |
| OmniSharp binary | ✅ C:\ProgramData\chocolatey\bin\OmniSharp.exe |
| vtsls binary | ✅ C:\Users\ashfa\AppData\Roaming\npm\vtsls (v0.3.0) |
| Binaries in PATH | ✅ Both found via which |
| Restarted Claude Code | ✅ Multiple times |
| LSP Tool Working | ❌ "No LSP server available" |

I'm still facing this same issue, is there a fix since this Bug is closed?

# macOS
claude --version
2.0.76 (Claude Code)

⏺ LSP(operation: "hover", symbol: "StrictServerInterface", in: "internal/pkg/oapiserver/server.gen.go")
  ⎿  No LSP server available for file type: .go

Same issue here, marked.
I'm worry about , there were some Workarounds ways maybe waste more time.

Same for me
No LSP server available for file type: .py

pyright installed and pyright-lsp plugin installed in claude.

@ravshansbox why are you making as thumbs down? what do you know that none of us know here about this issue?

@AshfaqGul because "me too" comments do not contribute to the solution in any way, why do not you just thumbs up the ticket? Furthermore, you are just disturbing everyone who has subscribed to the issue

@AshfaqGul because "me too" comments do not contribute to the solution in any way, why do not you just thumbs up the ticket? Furthermore, you are just disturbing everyone who has subscribed to the issue

who knows what's in your head with thumbs down. It confused everyone like if this issue does not apply here. This is good people can give more context to the issue. nothing wrong with that.

I'll second @AshfaqGul comment. The issue is closed and if there's is another solution or ticket that we can follow let us know please 🙏 Otherwise, it helps to see others have the same issue and that there's interest in having it resolved. Currently, it's unclear what is happening and a thumbs up doesn't tell me who else is having an issue or when they identified it.

The latest version of Claude Code, 2.0.76, was released on December 22nd. This issue was closed a few days later, so the fix hasn't been released yet. It seems that Anthropic closes issues when they are fixed in the codebase rather than when released, which is typical of Github projects, though they are usually open source so you can build yourself. Hopefully they will consider open sourcing Claude Code in 2026.

Aside, "me too" comments along with meta comments discouraging people from making "me too" comments have similar value, both meta commentary or emotional venting don't add a lot of value and generate similar amounts of noise. It's best to unsubscribe if it's becoming bothersome and wait for the next release.

Sorry for the double post but I just learned that there is a prerelease of 2.1.0 on npm published a few hours ago. I just tried it and it seemed to work for me using a custom plugin/LSP I built. If you are eager to try it, you can use npx @anthropic-ai/claude-code@2.1.0 to check and see if it works for you now.

https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md now on changelog as well

This issue was fixed for me as soon as I accepted the in-app suggestion to install the LSP server for my language. My theory is that they came back from holiday and fixed this one on the first day back, including the new prompt inside the app to get users to use it. (Easy to confirm by a bit of digging, but since it works for me, no need).

Works like a charm with the new v2.1.0!

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?

Works for me on v2.1.0 and v2.1.1 with Go code. I have trouble with C++ LSP (clangd-lsp) without an additional patch (#16729) but that's different than this issue.

Works now.

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

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

Thanks for the guide! However, it didn't work for me on v2.1.1.
Followed all the steps for pyright and typescript-language-server. /plugin shows ◉, which <binary-name> verified, and claude code restarted, but LSP is not being used (search tool instead)

All binaries are installed via npm -g install.
All plugins are installed at the user scope (~/.claude/settings.json)

Try to enable debug loggings and is stuck at error: unknown option '--enable-lsp-logging' 🥲

I just tried v2.1.1 and it doesn't work.

┌───────────────────┬───────────────────────────────────────────┬────────────┐
│      Plugin       │                 Contents                  │   Status   │
├───────────────────┼───────────────────────────────────────────┼────────────┤
│ lua-lsp           │ README.md only                            │ ❌ Broken  │
├───────────────────┼───────────────────────────────────────────┼────────────┤
│ rust-analyzer-lsp │ README.md only                            │ ❌ Broken  │
├───────────────────┼───────────────────────────────────────────┼────────────┤
│ typescript-lsp    │ README.md only                            │ ❌ Broken  │
├───────────────────┼───────────────────────────────────────────┼────────────┤
│ serena            │ Full plugin code (.mcp.json, plugin.json) │ ✅ Working │
└───────────────────┴───────────────────────────────────────────┴────────────┘

Same for golang and any other LSP plugin I install - CC does not recognize any.

@nazmulidris, @xobotyi, you can read the readme files from the plugin folders https://github.com/anthropics/claude-plugins-official/tree/main/plugins, just need some additional installs, and rerun the Claude Code. It is working for me, PHP and Typescript. You can also run /doctor command into the Claude Code, and copy and past the output to the Claude Code, to help with install.

@abicorios everything is there, doctor does not complaint on anything, though, CC aint even aware of LSP capabilities.

UPD1: And just for tests - installed serena plugin, everything works through serena's LSP capabilities now =\ (i understand that serena is 3rd party plugin and not an mcp at all but it recognis gopls and everything works through it)

Fixed on last update

I added ENABLE_LSP_TOOL=1 and launched claude. And the built in LSP tool seems to be working.

$ claude --version
2.1.1 (Claude Code)

$ ENABLE_LSP_TOOL=1 claude --dangerously-skip-permissions --permission-mode bypassPermissions

Here's the prompt transcript w/ claude:

> Is your built in LSP tool working? I started you with "ENABLE_LSP_TOOL=1". 
Find some typescript and rust files to read to verify it works.

Yes, the built-in LSP tool works for both Rust and TypeScript!

  Summary of test results:
  ┌────────────┬───────────────┬────────────────┬─────────────────────────┬──────────────────────────────────┐
  │  Language  │    Server     │ documentSymbol │          hover          │          findReferences          │
  ├────────────┼───────────────┼────────────────┼─────────────────────────┼──────────────────────────────────┤
  │ Rust       │ rust-analyzer │ ✅             │ ⚠️ (position-dependent) │ —                                │
  ├────────────┼───────────────┼────────────────┼─────────────────────────┼──────────────────────────────────┤
  │ TypeScript │ tsserver      │ ✅             │ ✅                      │ ✅ (found 3 refs across 2 files) │
  └────────────┴───────────────┴────────────────┴─────────────────────────┴──────────────────────────────────┘

The LSP servers are running and responding. Cases where no info was returned
are typically due to cursor position (on whitespace, keywords, or stdlib types
that aren't indexed).

  Available operations:
  - documentSymbol - list all symbols in a file
  - hover - get type/docs at cursor
  - goToDefinition - jump to definition
  - findReferences - find all usages
  - goToImplementation - find implementations
  - workspaceSymbol - search symbols across project
  - prepareCallHierarchy / incomingCalls / outgoingCalls - call hierarchy

I also had to install these LSP servers separately:

• rust-analyzer using cargo rustup component add rust-analyzer
• typescript lsp server using npm npm install -g typescript-language-server typescript

@nazmulidris not working for me; this issue should be re-opened

<img width="708" height="336" alt="Image" src="https://github.com/user-attachments/assets/b74c5ce8-a9a8-4cf2-9c65-9a6deafc6987" />

@evgenyfadeev can you update the marketplace?

Me being stooopid... kinda.

I was expecting the feature to be broadly available, since CC offered to install respective plugins and LSPs. And now, as @nazmulidris pointed - it is under the flag...

After setting env variable everything turned out to be working..

  - hover — Get documentation/type info for a symbol
  - documentSymbol — List all symbols in a file
  - workspaceSymbol — Search symbols across the workspace
  - goToImplementation — Find implementations of interfaces/abstract methods
  - prepareCallHierarchy — Get call hierarchy item at a position
  - incomingCalls — Find callers of a function
  - outgoingCalls — Find callees from a function

  All operations require a file path, line number, and character offset. The LSP server must be configured for the file type — if gopls is running for this Go project, these should work.

❯ try discover anything in this project using lsp? 

⏺ Let me probe the LSP with a few operations on key files:

⏺ LSP(operation: "documentSymbol", file: "analyzer/analyzer.go")
  ⎿  Found 33 symbols (ctrl+o to expand)
  ⎿  Running PostToolUse hooks… (1/2 done)

⏺ LSP(operation: "workspaceSymbol", file: "analyzer/analyzer.go")
  ⎿  Found 0 symbols 
  ⎿  Running PostToolUse hooks… (1/2 done)

@evgenyfadeev can you update the marketplace?

Indeed "updating the marketplace" helped! Hope this is documented, I had no idea that I need to do this. Thanks!

Given that built in LSP tool works, is there a need to have the serena plugin as well? This is assuming that the built in LSP tool has adequate coverage of the languages used.

Problem

It seems like the startupTimeout in the marketplace is the root cause for the LSP that could not be loaded. For LSPs that do not have the startupTimeout, such as pyright, it works, but for jdtls, which as startupTimeout, does not work.

⏺ Step 1: Confirmed - startupTimeout: 120000 is present and LSP fails.

  Now let me remove it and test again:

⏺ Bash(/tmp/apply-claude-code-lsp-fix.sh --fix-plugins 2>&1 || (curl -sL "https://gist.githubusercontent.com/Zamua/f7ca58ce5dd9ba61279ea195a01b190c/raw" -o /tmp/apply-…)
  ⎿  Fixing plugin configs...
     ✓ Fixed kotlin-lsp: removed unsupported "startupTimeout" from kotlin-lsp
     ✓ Fixed jdtls-lsp: removed unsupported "startupTimeout" from jdtls

⏺ Bash(grep -A8 '"jdtls":' ~/.claude/plugins/marketplaces/claude-plugins-official/.claude-plugin/marketplace.json 2>/dev/null)
  ⎿          "jdtls": {
               "command": "jdtls",
               "extensionToLanguage": {
     … +6 lines (ctrl+o to expand)

⏺ Step 2: Removed - startupTimeout is now gone from the config.

  ★ Insight ─────────────────────────────────────
  Why a restart is needed:
  - LSP servers are loaded once during Claude Code startup
  - The server configs are read from marketplace.json at that time
  - Modifying the config mid-session doesn't trigger a reload
  - The LSP manager caches the server registry for the session lifetime
  ─────────────────────────────────────────────────

⏺ LSP(operation: "documentSymbol", file: "/Volumes/workplace/A2X-Fix/src/A2XDataModel/src/com/amazon/a2x/datamodel/util/DealUtil.java")
  ⎿  Found 14 symbols (ctrl+o to expand)

⏺ Confirmed: startupTimeout is the root cause.
  ┌────────────┬────────────────┬───────────────┐
  │   State    │ startupTimeout │   jdtls-lsp   │
  ├────────────┼────────────────┼───────────────┤
  │ Before fix │ 120000         │ ❌ Not loaded │
  ├────────────┼────────────────┼───────────────┤
  │ After fix  │ Removed        │ ✅ Working    │
  └────────────┴────────────────┴───────────────┘
  ★ Insight ─────────────────────────────────────
  Root Cause Analysis:
  1. The field exists in marketplace config because JDTLS can take 30-120s to initialize (it loads the entire Java project model)
  2. Claude Code's LSP loader doesn't implement startupTimeout yet - when it encounters this unknown field, it fails validation and skips the entire server rather than ignoring the field
  3. Pyright works because its config has no startupTimeout field
  4. The fix: Remove the field until Claude Code implements support for it

  Workaround persistence issue: The marketplace config gets refreshed periodically from the remote repo, restoring startupTimeout. You may need to re-run --fix-plugins after updates.
  ─────────────────────────────────────────────────

Fix

Set up a SessionStart hook to remove the startupTimeout from the marketplace since the marketplace config gets refreshed periodically from the remote repo.

  1. Hook script: ~/.claude/hooks/fix-lsp-plugins.sh
    - Runs silently on every session start
    - Removes startupTimeout and shutdownTimeout from all LSP configs
    - Uses Node.js for proper JSON manipulation (already available)
  2. SessionStart hook in settings.json:
    - Triggers before plugins load
    - 5-second timeout (more than enough)
    - Empty matcher = runs for all sessions

~/.claude/hooks/fix-lsp-plugins.sh
fix-lsp-plugins.sh

in the ~/.claude/settings.json

     "SessionStart": [
       {
         "matcher": "",
         "hooks": [
           {
             "type": "command",
             "command": "~/.claude/hooks/fix-lsp-plugins.sh",
             "timeout": 5000
           }
         ]
       }
     ],

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.