[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

Currently, LSP in Claude Code is configured per-user via plugins. There is no project-level equivalent of .mcp.json for LSP servers. This means 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 what 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 team members who miss a server. The .mcp.json pattern already solved this exact problem for MCP servers — LSP deserves the same treatment.

Proposed Solution

Add a .claude/.lsp.json 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 file format should match the LSP configuration structure already used in plugins (plugin.json lsp field), so there is no new schema to learn. The interface should show a trust prompt on first use (similar to MCP server approval) before starting the declared servers.

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 with 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 to use an alternative language server. The plugin also can't be committed to the project repo in a way that other developers pick up automatically.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Hypothetical scenario (to illustrate the workflow, not my exact stack):

1. A team is working on a project that uses 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 joins the team, clones the repo, and runs Claude Code — they get no LSP coverage at all for either language. Someone has to walk them through building and installing the same custom plugins
4. With a .claude/.lsp.json checked into the repo, the new developer would get prompted to approve the LSP config on first run, and both servers would start automatically — no custom plugin work needed

Additional Context

• The precedent is already set: .mcp.json provides project-scoped MCP configuration with a trust/approval model. LSP config should follow the same pattern.
• Also submitted via /feedback (ID: 78989f34-83b1-421d-a1d9-3eaeba8eeaa0) as part of a combined request; splitting into separate issues per guidelines.