# Claude Code LSPs: a marketplace that wires language servers into Claude Code > The Piebald-AI/claude-code-lsps repository is a Claude Code plugin marketplace that packages language servers for around thirty languages, with per-language setup instructions and a validation workflow that keeps the generated configuration honest. It suits a developer who wants go-to-definition and hover inside Claude Code, and it assumes Claude Code 2.1.50 or newer. **Piebald-AI/claude-code-lsps** — Claude Code Plugin Marketplace with LSP servers - Repository: https://github.com/Piebald-AI/claude-code-lsps - Website: https://www.reddit.com/r/ClaudeAI/comments/1otdfo9/lsp_is_coming_to_claude_code_and_you_can_try_it/ - Stars: 522 · Forks: 62 - Language: JavaScript - License: not declared - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/piebald-ai-claude-code-lsps ## What the marketplace is, and why the feature arrived late The repository is a Claude Code marketplace with plugins that offer LSP servers, and the readme lists the languages covered in one long sentence: TypeScript, Rust, Python, Go, Java, Kotlin, Scala, C/C++, PHP, Ruby, C#, PowerShell, HTML/CSS, LaTeX, Julia, Vue, Svelte, OCaml, BSL for 1C:Enterprise, Ada, Dart, Solidity, Elixir, Bash, and Markdown or mdbase. The timing is the interesting part of the story, and the readme is clear about it. Claude Code officially supports LSP, and in 2.0.74 it was added to the changelog. Previously the new LSP builtin tool had to be enabled manually through an environment variable, $ENABLE_LSP_TOOL=1. That sequence explains the shape of this project. The feature arrived in a version with a manual on-switch, so early users had to know it existed and to set a variable, and the ecosystem of third-party plugins that makes the feature useful followed the announcement. This repository is one of those plugins, and the marketplace it publishes is the mechanism by which a Claude Code user says which language servers to start. The readme also states the version constraint plainly: the marketplace currently targets Claude Code 2.1.50 or newer, with 2.1.52 as the latest release, in order to use modern LSP configuration fields such as startupTimeout. That field is the reason for the constraint. A language server that fails to start within a timeout is a server that fails silently, and a configuration format that can express the timeout is the difference between a plugin that works and a plugin that times out. The licence field is one that GitHub cannot classify and the terms are not stated in the documentation, so there is no clear grant to reuse the configuration files or the scripts in another project. The primary language is JavaScript, the default branch is main, and the last push to the repository was on 2026-07-25. ## What the plugins give Claude, and what they cost The list of operations is the point of the whole project, and it is worth reading as a capability list. Claude can use the LSP tool to go to the definition for symbols, to go to the implementation for symbols, to hover over symbols, to list all the symbols in a file, to find all references to a symbol, to search for symbols across the workspace, to get the call hierarchy for a given function, to find all functions that call a given function, and to find all the functions and methods called by a given function. Read as a pair of groups, the first six are lookup operations and the last three are structural ones. The lookup operations are the ones that replace a guess. When Claude is told to change a call site, an editor-assisted model can look up the symbol's definition rather than guess at the file, and the call hierarchy operations are the ones that answer the question of what breaks if a signature changes. The cost is visible in the repository tree. There is a directory per language server, and the list includes rust-analyzer, basedpyright and pyright, ty, gopls, jdtls, clangd, ruby-lsp, phpactor, php-lsp, powershell-editor-services, elixir-ls, metals, ocaml-lsp, omnisharp, kotlin-lsp, julia-lsp, lean4-lake-lsp, lean4-lean-lsp, solidity-language-server, svelte, swift-lsp, vue-volar, vscode-langservers, vtsls, typescript-language-server, graphql-lsp, haskell-language-server, ada-language-server, mdbase-lsp, bash-language-server, texlab, terraform-ls, tofu-ls, gleam, dart and bsl-lsp, alongside a scripts/ directory, a .claude-plugin/ directory, CLAUDE.md and a README. Each of those is a separate program with its own release cycle, its own configuration dialect and its own idea of what a project root is. The marketplace turns that into a set of consistent configurations, which is real work even though the individual servers are somebody else's projects. There is a commercial layer around it. The top of the readme is an announcement for Piebald, described as an agentic AI developer experience, with a download link, a Discord and a social account, and the whole LSP section is positioned as something to scroll down to. So this repository is the community-facing half of a product that also has a paid tier, which is worth knowing before you depend on it. ## Installing: the marketplace, the plugins, and the patch There are three steps, and they are documented separately because they are different kinds of action. The first is to make Claude Code aware of the marketplace. Run claude, then issue the plugin marketplace add command for Piebald-AI/claude-code-lsps. The second is to enable the plugins you want. Run claude, type /plugins, tab to Marketplaces, enter the claude-code-lsps marketplace and choose Browse plugins, select the plugins with the spacebar, for example TypeScript and Rust, press i to install them, and restart Claude Code. The third is the patching step, and it is the one to look at hardest. Run npx tweakcc --apply, and tweakcc automatically detects your Claude Code installation, npm or native, and applies the necessary patches, patching the installation to make the builtin LSP support usable. The readme is candid that the tool does a bunch of other things as well, letting you customise all the system prompt parts, create new themes, change the thinking verbs, and more. That description is the reason to think before running it. A tool that rewrites your installation of another product, that also rewrites system prompts and themes, is a tool with a large blast radius, and the fact that it comes through npx means the code that runs is whatever is on the registry that day rather than a version you reviewed. The order of operations also matters, because the marketplace and the patch are doing different jobs. The marketplace supplies the configuration that says which server to start and how to talk to it, and the patch makes the host able to use it. Installing plugins without the patch may give you a configuration that never runs, depending on your Claude Code version. And then there is the third dependency, which is the language server itself. The plugins are configuration, and the servers are separate programs that the documentation expects you to install. ## The per-language setup, and the choices it forces on you The language-specific section is the longest part of the documentation, and it is the part that shows the real cost of this approach. For Rust, the plugin uses rust-analyzer, the official modern Rust language server and the same one used by the official VS Code extension, and with rustup the install is a single component add: ```bash rustup component add rust-analyzer ``` with the requirement that the rust-analyzer executable be in your PATH. For JavaScript and TypeScript there are two plugins and a warning that applies to both. typescript-language-server installs with typescript as a global package, and vtsls installs the language server package the same way. The note is explicit: install only vtsls or typescript-language-server since they both cover the same languages. That is a real decision rather than a detail. Two servers covering the same languages means the marketplace is offering a choice, and a user who installs both will end up with two servers competing for the same files, with the slower one starting and the faster one waiting for the port. For Python there are two as well, which is a newer problem. pyright is recommended for its speed and excellent type checking, and ty is described as Astral's extremely fast Python type checker, installed with uv tool install ty or with pip, with the note that ty auto-detects pyproject.toml for project configuration. For Go the plugin is gopls, the official Go language server, installed with go install, with the note to make sure the Go bin directory is on your PATH, usually at ~/go/bin. For Java it is Eclipse JDT Language Server, jdtls, which requires a Java 21 or newer runtime. Two things stand out across the list. The first is that the servers are not bundled, so a user enabling the Rust plugin and not having rustup installed gets a plugin that does nothing, and the documentation's job is to tell you the extra step per language. The second is that PATH is the recurring requirement, and it is the kind of requirement that is satisfied on a developer workstation by accident, in a container by luck, and in a fresh CI image by an afternoon of debugging. ## The contributor workflow, which is the part that shows the project is disciplined The most instructive part of the documentation is the section for contributors, because it describes how a directory full of generated configuration stays consistent. The .lsp.json files are the canonical source of the LSP configuration, and the lspServers entries in the .claude-plugin/marketplace.json are generated from those .lsp.json files. Generated blocks are not to be hand-edited. The sync script, sync-lsp-to-marketplace, only updates plugins that already exist in the marketplace plugins array, so a new plugin directory needs a marketplace entry added first. And validate-lsp-definitions will fail if a plugin directory exists but is not referenced in the marketplace plugins array. So there is one source of truth per plugin, a generator, and two validators, one for the definitions and one for the runtime. After any configuration change the workflow is a single command: ```bash node scripts/validate-all.mjs ``` which runs sync-lsp-to-marketplace.mjs, validate-lsp-definitions.mjs and validate-runtime-marketplace.mjs, with an optional --skip-runtime flag to skip the Claude runtime validation. That is a sensible division. The sync step propagates a change to the generated file, the definitions check catches a directory that nothing references, and the runtime check starts Claude Code and confirms the marketplace actually loads, which is the kind of thing that only fails in the real product. The alternative, editing the generated marketplace file by hand, produces a repository that looks fine and breaks the next time somebody regenerates it, and the cost of that mistake grows with the number of languages. The design decision here is not clever, and that is the point: the thirty-plus plugin directories are only maintainable because one file is canonical and the rest is generated. ## Where the LSP marketplace is the wrong tool The first limit is that it is a Claude Code feature rather than a general one, and the version constraint is real. The marketplace targets Claude Code 2.1.50 or newer, and an earlier installation is not going to be fixed by the configuration, because the field the marketplace relies on, startupTimeout, is a field that version understands and earlier versions do not. The second is the patching dependency, and it is the strongest objection. Running npx tweakcc --apply fetches and executes code that modifies your installation of a commercial product, that also customises system prompts and themes, and that is delivered from a registry rather than from a version you pinned. For a developer who wants language intelligence in their agent, that is a heavy price for a feature the vendor now supports natively in a later version, and the sensible comparison is with what Claude Code does without any of it. The third is that the servers are not part of the package. Every language is another install, another PATH entry and another version to track, and a team that standardises on one language server per language now has a matrix of tools to maintain, each with its own release cadence and its own compatibility with the editor or agent that starts it. The fourth is that the value depends on the language. For a language with a strong server, the difference between an agent that can navigate a codebase and one that greps is large. For a language with a thin or absent server, the plugin is a formality, and the list in the documentation includes entries where the server is a wrapper around a linter rather than a type-aware analyser. And the fifth is that a language server is not free to run. Each one is a process that indexes a project, and several of the ones in the list are the same programs that an editor already runs, which means you may end up with two indexes of the same repository in memory. That is a real cost on a large codebase, and it is the cost that a purely text-based approach does not have. ## Conclusion Claude Code LSPs is worth adding if you work in a language where Claude Code's own reading of the codebase is weaker than a language server's, because the plugins point Claude at the same servers an editor uses, so the definitions, references and call hierarchy come from the compiler's own view of the project rather than from a text search. It is the wrong tool if your language has no server or if you are happy with grep. Before you install it, check three things: that you are on Claude Code 2.1.50 or newer, since the marketplace targets that version to use modern LSP configuration fields such as startupTimeout, and that you read the patching step, because the documentation says to run npx tweakcc --apply, which detects your installation, npm or native, and patches it so the built-in LSP support is usable, and a script that modifies your installation of another product deserves to be looked at first; and that you install the language server yourself, because the marketplace ships configuration and the instructions, not the servers, so a TypeScript plugin still needs typescript-language-server or vtsls on your PATH, and the same is true of rust-analyzer, pyright, ty, gopls and the rest. ## FAQ ### What does the Claude Code LSPs marketplace give me? It gives Claude Code the LSP builtin tool for go to definition, go to implementation, hover, document symbols, find references, workspace symbol search, call hierarchy, incoming calls and outgoing calls. The repository publishes plugins for around thirty languages, each of which points Claude Code at the corresponding language server so the answers come from the project's own type information rather than from text matching. ### How do I install the LSP plugins in Claude Code? Run claude and issue the plugin marketplace add command for Piebald-AI/claude-code-lsps, then run claude again, type /plugins, tab to Marketplaces, enter the claude-code-lsps marketplace, choose Browse plugins, select the plugins you want with the spacebar, press i to install them and restart Claude Code. The readme also says to run npx tweakcc --apply so that the built-in LSP support is usable. ### Do I need to install the language servers separately? Yes. The marketplace ships the configuration rather than the server, so each language has its own setup step. Rust needs rust-analyzer added through rustup, TypeScript needs typescript-language-server or vtsls installed globally, Python needs pyright or ty, Go needs gopls installed with go install, and Java needs Eclipse JDT Language Server with a Java 21 or newer runtime. Each server's executable has to be on your PATH. ## Sources - [Issues](https://github.com/Piebald-AI/claude-code-lsps/issues) - [Piebald-AI/claude-code-lsps on GitHub](https://github.com/Piebald-AI/claude-code-lsps) - [Project website](https://www.reddit.com/r/ClaudeAI/comments/1otdfo9/lsp_is_coming_to_claude_code_and_you_can_try_it/) - [README](https://github.com/Piebald-AI/claude-code-lsps/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/piebald-ai-claude-code-lsps