[FEATURE] Add /lsp slash command for LSP server status

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Currently, Claude Code provides no built-in way to view the status of LSP servers running in a session. Unlike MCP servers, which have the /mcp slash command that shows server names, connection status, available tools, and configuration details, LSP servers operate invisibly. The only way to confirm an LSP server is running is to check debug logs (~/.claude/debug/) or notice that go-to-definition responses are faster than usual. There's no way to quickly answer basic questions like: "Is pyright actually running right now?", "Which languages have LSP coverage in this session?", or "Why isn't my Go LSP initializing?" This makes troubleshooting painful and leaves developers unsure whether they're getting LSP-powered code intelligence or falling back to text search.

Proposed Solution

Add a /lsp slash command that displays a status dashboard for all LSP servers, mirroring what /mcp does for MCP servers.

Running /lsp should show:

• Server list — all configured LSP servers (from plugins, project config, user config)
• Status — connected, initializing, error, or not installed for each server
• Languages/extensions — which file types each server handles (e.g., .ts, .tsx → typescript-language-server)
• Source — where the config came from (plugin name, project scope, user scope)
• Diagnostics count — optionally, how many active warnings/errors each server is reporting

Example output:

LSP Server Status

● typescript-language-server  connected   .ts .tsx .js .jsx   (plugin: typescript-lsp)
● pyright-langserver          connected   .py                 (plugin: pyright-lsp)
○ gopls                       not found   .go                 (plugin: go-lsp)
  └─ Install: go install golang.org/x/tools/gopls@latest

For servers in error state, it should show the error message and suggest fixes (e.g., "Executable not found in $PATH").

Alternative Solutions

I've tried the following workarounds:

1. Checking debug logs manually — Running cat ~/.claude/debug/*.log | grep LSP after a session to verify servers initialized. This is tedious, only works after the fact, and requires knowing the log format.

1. Running /plugin and inferring status — The /plugin command lists installed plugins including LSP ones, but it doesn't show whether the underlying language server process is actually running or healthy. A plugin can be installed while the binary is missing from PATH.

1. Asking Claude directly — Typing "are my LSP servers running?" sometimes works, but Claude doesn't always have reliable access to this information, and the response is inconsistent.

The /mcp command already provides exactly this pattern for MCP servers and is very useful for debugging. The same UX should exist for LSP.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

Hypothetical scenario (to illustrate the workflow):

1. A developer opens Claude Code in a Python + TypeScript monorepo where they have both LSP plugins installed
2. They notice Claude is using grep-based search instead of go-to-definition for Python files, suggesting pyright isn't working
3. They run /lsp and immediately see that pyright shows status "not found" with a hint that the binary isn't in PATH
4. They run pip install pyright, restart Claude Code, run /lsp again, and confirm both servers show "connected"
5. Without /lsp, this same debugging process would take 10+ minutes of checking logs, reinstalling plugins, and guessing — with it, 30 seconds

Additional Context

• The /mcp command is the direct precedent — it shows server name, status (connected/error), and available tools. /lsp should follow the same visual format for consistency.
• A claude lsp list CLI equivalent (like claude mcp list) would also be valuable for scripting and CI checks, but the slash command is the higher-priority need.
• This pairs naturally with the LSP plugin system introduced in v2.0.74. As more teams adopt LSP plugins, discoverability and debugging become increasingly important.
• Also submitted via /feedback (ID: 78989f34-83b1-421d-a1d9-3eaeba8eeaa0) as part of a combined request; splitting into separate issues per guidelines.