[FEATURE] Project-scoped LSP configuration

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

LSP in Claude Code is configured per-user via plugins. There is no project-level equivalent of .mcp.json for LSP servers, so every developer on a team must independently configure the correct LSP setup for a project. For languages without an official plugin in the marketplace, or when a team prefers a different language server than the official plugin provides, each developer has to build and install a custom plugin locally. On polyglot codebases this leads to inconsistent setups, wasted onboarding time, and degraded code intelligence for anyone who misses a server. The .mcp.json pattern already solved this exact problem for MCP servers — LSP deserves the same treatment.

To be precise about what exists today: .lsp.json is already a filename in the plugin system — it lives inside a plugin directory alongside plugin.json and defines that plugin's servers. What doesn't exist is a project-root equivalent that Claude Code discovers on its own. Dropping the same file at a repo root has no effect, because nothing scans for it there. This request is for discovery at project scope, not a new schema.

Proposed Solution

Add a project-scoped LSP config file that declaratively lists the LSP servers a project needs, so that when any team member runs claude in the repo, the correct language servers are automatically available.

The format should match the LSP configuration structure already used in plugins, so there is nothing new to learn:

{
  "elixir-ls": {
    "command": "elixir-ls",
    "args": ["--stdio"],
    "extensionToLanguage": { ".ex": "elixir", ".exs": "elixir" },
    "transport": "stdio"
  }
}

The interface should show a trust prompt on first use — the same approval model as project-scoped MCP servers — before starting any declared server. Precedence should follow the existing pattern: user config overrides project config, project config overrides plugin defaults.

Alternative Solutions

The only real workaround today is building a custom plugin for each LSP server you need: creating a plugin directory, writing a plugin.json, adding the LSP config, and having every team member install it. This is heavy overhead for what is essentially a few lines of configuration, especially for languages not covered by the official marketplace or when you want an alternative language server. The plugin also can't be committed to the project repo in a way that other developers pick up automatically.

Adding a marketplace entry to .claude/settings.json gets closer, but it still requires publishing and maintaining a plugin wrapper around what should be a checked-in config file. The plugin wrapper is precisely the overhead this request aims to remove.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

1. A team works on a project using Elixir with an Elm frontend — neither has an official LSP plugin in the Claude Code marketplace
2. One developer sets up elixir-ls and elm-language-server through a custom plugin they built locally
3. A new developer clones the repo and runs Claude Code — no LSP coverage at all for either language. Someone has to walk them through building and installing the same custom plugins
4. With a project-scoped LSP config checked into the repo, the new developer gets prompted to approve it on first run, and both servers start automatically — no custom plugin work needed

Additional Context

• Previously filed as #39472 — 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: #89473 (a /lsp status command).
• The precedent is already set: .mcp.json provides project-scoped MCP configuration with a trust/approval model. LSP config should follow the same pattern.
• Several third-party guides instruct users to create a project-root .lsp.json, which appears to be a misreading of the plugin-internal file of the same name. That confusion is itself evidence the expectation exists — people assume project-scoped LSP config already works, then find out it doesn't.