[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

Configuration and settings

Use Case Example

Scenario I've hit repeatedly on a Python + TypeScript monorepo:

1. Both LSP plugins are installed, so I assume both servers are running
2. Claude starts using grep-based search instead of go-to-definition on Python files — the only signal that something is wrong, and an easy one to miss
3. With /lsp, pyright would immediately show status "not found" with a hint that the binary isn't in PATH
4. pip install pyright, restart, run /lsp again, confirm both show "connected"
5. Without /lsp, this takes 10+ minutes of checking logs, reinstalling plugins, and guessing — with it, 30 seconds

Additional Context

• Previously filed as #39473 — closed as not planned by the stale bot with no maintainer response. Re-filing since the issue can't be reopened. Verified still missing on v2.1.245.
• Companion request: #89472 (project-scoped LSP configuration). Both came out of the same setup friction.
• 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.
• The LSP plugin ecosystem has grown substantially since this was first filed (community marketplaces now cover 20+ languages). More installed servers means more silent failures when a binary isn't on PATH — discoverability matters more now than it did in March.